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1.0  INTRODUCTION 


This  document  represents  the  results  of  a  study  commissioned  under  AIR- 
TASK  A533533F/001D/1W05720000  in  support  of  the  NAVAIR  Avionics  Components  and 
Subsystems  Program.  The  background  and  objectives  of  the  overall  program  as 
stated  in  reference  (e)  are: 

Background 

"A  major  concern  within  the  military  avionics  community  is  the  prolifera¬ 
tion  of  unique  avionics  equipment  that  increases  with  each  new  aircraft  devel¬ 
opment.  Because  of  the  limited  quantities  of  avionics  equipment  associated 
with  any  particular  aircraft,  a  growing  cost  burden  has  been  experienced  in 
the  areas  of  multiple  subsystem  development,  procurement,  logistics,  mainte¬ 
nance,  and  total  subsystem  life  cycle  cost  (LCC).  The  Avionics  Components  and 
Subsystems  Program  (AVCS)  program  was  formulated  by  NAVAIR  to  reduce  prolifer¬ 
ation  of  unique  avionics  equipment  and  life  cycle  costs  by  providing  a  family 
of  Government  Furnished  Equipment  (GFE)  common  to  miltiple  aircraft.  The  AVCS 
program  provides  for  the  development  of  avionics  equipment  supportive  of,  but 
separate  from,  major  weapon  system  acquisitions." 

Objectives 

"The  objectives  of  the  AVCS  program  are  listed  below: 

(1)  provide  comprehensive  planning  and  analysis  of  current  and  future 
user  needs, 

(2)  reduce  proliferation  and  associated  costs  of  unique  weapon  system 
avionics, 
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(3)  maximize  commonality  of  hardware  and  software  across  multiple  air¬ 
craft, 

(4)  maximize  flexibility  and  grcwth  potential  by  careful  subsystem 
architecture  design  and  incorporation  of  digital  data  bus  interface 
capability , 

(5)  select  mature  technologies,  suitable  for  military  avionics  appli¬ 
cations,  that  will  be  available  and  logistically  supportable  for  the 
projected  service  life  of  the  equipment, 

(6)  minimize  the  need  for  organizational  level  Ground  Support  Equipment 
(GSE)  by  careful  system  architecture  design  and  functional  parti¬ 
tioning,  and  by  implementing  Built-In-Test  (BIT)  and  In-Flight  Per¬ 
formance  Monitoring  (IFPM)  to  meet  fault  detection  and  isolation  re¬ 
quirements,  and 

(7)  provide  for  the  development  of  common  GFE  avionics,  separate  from 
major  weapon  system  acquisition,  that  will  receive  rigorous  testing 
to  assure  reliability  and  supportability. " 

This  report  was  prepared  in  direct  support  of  objective  (1)  in  order  to 
provide  recommendations  relative  to  achieving  the  remaining  AVCS  program  ob¬ 
jectives. 

The  basic  objective  of  the  AVCS  program  is  commonality  among  avionics  in 
different  platforms.  The  few  elements  of  Naval  avionics  that  are  common  today 
primarily  came  about  because  of  GFE  (which  in  many  cases  was  developed  as  con¬ 
tractor  furnished  equipment  (CFE)).  From  the  weapons  system  point  of  view, 

GFE  is  equipment  that  must  be  adapted  to  rake  it  work  since  the  GFE  is  rarely 
directly  applicable  to  a  new  or  upgraded  weapons  system  architecture.  The 
basic  problem  is  that  the  weapons  system  contractor  is  provided  a  piece  of 
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equipment  (GFE)  which  was  not  designed  as  a  part  of  the  weapons  system  in 
which  it  is  being  installed.  When  an  upgrade  of  a  subsystem  or  element  is 
necessary,  it  is  often  made  as  a  "form,  fit,  functional  replacement."  What 
occurs  in  reality  is  that  boxes  are  built  to  be  compatible  with  the  adapta¬ 
tions  made  in  the  weapons  system  to  accommodate  the  original  GFE.  For  the  GFE 
equipment  items  of  the  AVCS  program  to  be  completely  successful,  they  must  be 
designed  as  part  of  a  weapons  system  and  not  as  pieces  of  equipment. 

It  is  not  probable  that  the  Navy  will  ever  have  an  ideal  weapons  system 
in  which  every  element  is  designed  to  do  exactly  what  is  necessary  to  support 
the  mission  of  that  weapons  system.  If  technological  superiority  is  to  be 
maintained  within  the  limits  of  aircraft  constraints,  then  an  attempt  must  be 
made  to  approach  the  ideal  weapons  system.  This  attempt  is  most  likely  to  re¬ 
quire  higher  levels  of  subsystem  integration  in  order  to  achieve  increased 
capabilities  with  finite  resources.  In  order  to  make  AVCS  compatible  with  fu¬ 
ture  avionics  needs  common  equipment  must  be  integratable.  The  primary  goal 
of  this  study  is  to  define  ways  of  insuring  that  future  avionics  equipment 
items  are  elements  of  a  weapons  system  that  can  be  used  across  a  range  of 
weapon  systems  and  are  compatible  with  future  growth  (increased  integration). 

2 . 0  APPROACH 


In  the  preparation  of  this  report,  the  analysis  of  current  and  future 
needs  for  weapons  system  avionics,  with  particular  emphasis  on  multlplatforra 
avionics  requirements,  was  attempted.  The  analysis  followed  this  path  in  in 
quiry : 

o  What  does  the  Navy  need  in  terms  of  a  modern,  flexible,  practical 
avionics  suite  (overall  and  core  avionics  requirements)? 

o  What  architecture  can  be  used  to  satisfy  the  need  (architecture  de 
sign)? 


3 


Report  No.  NADC  81235-20 


o  What  are  the  specific  subsystem  requirements  of  the  architecture 
(interfaces  to  the  architecture)?  and 

o  What  action  is  necessary  to  allow  the  architecture  to  evolve  (recora- 
rae ndations)? 

The  effectivity  of  the  results  of  this  process  would  appear  to  be  highly 
dependent  on  the  practical  acceptance  of  the  architectural  design.  For  some 
of  the  recommended  hardware  developments,  this  is  true.  The  recommendations 
regarding  interface  requirements,  standards,  and  procurement  practices,  how¬ 
ever,  were  made  as  independent  of  the  specific  architecture  as  possible.  This 
was  done  by  attempting  to  address  the  interfacing  of  equipment  from  a  func¬ 
tional  point  of  view. 

3.0  GENERAL  ARCHITECTURAL  REQUIREMENTS 

The  purpose  of  this  report  is  to  develop  a  multiplatform  avionics  archi¬ 
tectural  concept  that  allcws  emerging  technologies  and  the  realities  of  cur¬ 
rent  and  future  weapon  systems  to  come  together.  The  requirements  for  a  com¬ 
mon  architecture  that  would  ideally  satisfy  the  Navy's  needs  are: 

a.  )  Technology  transparent  functional  partitioning 

b.  )  Compatibility  with  the  accommodation  of  specialized  subsystems 

c. )  Survivability 

d.  )  Maximum  commonality 

e.  )  Efficient  hardware  utilization 

f. )  Minimization  of  interconnect  requirements 

g. )  Elimination  of  superfluous  redundancy 

h.  )  Sufficient  throughput  capability 

i.  )  Applicability  to  nultlple  platforms 

j. )  Compatibility  with  Red/31ack  requirements 

k. )  Provision  of  simple  control  and  display 
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l.  )  Compatibility  with  procurement 

m.  )  Allowance  for  growth. 

3. 1  ASSESSMENT  OF  REQUIREMENT 

The  ideal  architecture  requirements  cannot  be  met  in  any  real  sense.  It 
is  important  to  realize  that  many  r  the  requirements  are  diametrically  op¬ 
posed  and,  as  a  result,  any  architecture  will  trade-off  the  requirements 
against  each  other.  One  method  of  resolving  the  conflicts  between  require¬ 
ments  is  to  prioritize  them.  However,  rigidly  enforced  priorities  cannot  al¬ 
low  for  intelligent  resolution  of  specific  conflicts.  The  best  way  to  achieve 
an  optimum  architecture  is  to  examine  all  the  conflicts  and  make  decisions  on 
a  problem  by  problem  basis.  In  the  following  discussion  each  item  in  para¬ 
graph  3.0  is  discussed  and  the  conflicts  with  other  items  in  paragraph  3.0  are 
then  examined.* 

a. )  Technology  Transparent  Functional  Partitioning.  This  is  one  area  in 
which  very  few  conflicts  exi3t  since  it  is  a  natural  fallout  of  a 
properly  organized  architecture. 

Efficient  hardware  utilization  in  some  cases  would  require 
the  removal  of  functional  partitions;  however,  in  order  to 
maintain  growth  capability  and  flexibility,  the  logical 
partitioning  of  functions,  particularly  to  allow  technol¬ 
ogy  transparency,  should  not  be  redirected  solely  to 
achieve  efficient  hardware  utilization. 


*  The  circled  letters  refer  to  Items  In  paragraph  3.0  which  are  in  conflict 
with  the  item  under  discussion. 
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b. )  Compatibility  with  Accoramodat lag  Specialized  Subsystems.  This  re¬ 
quirement  creates  the  greatest  number  of  conflicts  since  It  expli¬ 
citly  states  that  the  architecture  must  accommodate,  but  not  In¬ 
clude,  certain  functions. 


@  The  departure  from  any  architecture  has  survivability  impact, 
particularly  in  accommodating  fault  tolerance  and  redundancy 
requirements.  Provision  within  the  architecture  for  surviva¬ 
bility  of  unforeseeable  requirements  is  not  considered  prudent. 
Hence,  survivability  issues  for  specialized  subsystems  are  part 
of  that  subsystem  and  affect  the  architecture  only  where  inter¬ 
faces  with  the  architecture  are  required. 


@ 


Maximum  commonality  cannot  be  achieved  when  specialized  subsys¬ 
tems  are  allowed.  Enforcing  commonality  on  a  specialized  sub¬ 
system  is  usually  unsuccessful  and  often  inefficient.  If  suf¬ 
ficient  standards  are  applied  then  interfaces,  whether  or  not 
they  connect  to  the  architecture,  can  and  should  be  made  com- 
patable.  Common  modules  should  be  required  only  when  they  do 
not  Impact  overall  subsystem  design. 


( e )  Efficient  hardware  utilization  does  not  allow  specialized  sub¬ 

systems.  This  conflict  should  be  resolved  when  the  decision  is 
made  to  allow  a  subsystem  to  be  specialized.  A  specialized 
subsystem  is  required  when  the  basic  architecture  cannot  do  the 
job;  however,  there  are  in  all  probability  one  or  more  parts  of 
the  job  that  can  be  done  within  the  architecture.  Hence,  when 
a  subsystem  is  declared  special,  those  functions  of  that  sub¬ 
system  that  are  to  be  performed  within  the  architecture  should 
be  explicitly  stated  to  allow  maximum  hardware  utilization. 


® 


Minimizing  interconnect  requirements  cannot  be  accomplished  ef¬ 
fectively  with  specialized  subsystems,  and  only  cursory  re¬ 
quirements  should  be  applied  in  this  area. 
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Superfluous  redundancy  will  result  In  a  specialized  subsystem 
when  unnecessary  redundancy  for  the  subsystem  is  implemented. 
Eliminating  the  superfluous  redundancy  by  utilizing  the  archi¬ 
tecture  is  rarely  a  possibility  because,  by  definition,  if  the 
architecture  could  do  the  job,  the  subsystem  would  not  need  to 
be  specialized.  If  the  mission  critical  portion  of  the  subsys¬ 
tem  can  be  accomplished  within  the  architecture,  then  the  spe¬ 
cialized  subsystem  is  being  utilized  only  for  accessory  func¬ 
tions.  Superfluous  redundancy  can  be  eliminated  for  special¬ 
ized  subsystems  by  limiting  the  redundancy  requirements  and 
following  the  guidelines  above  for  efficient  hardware  utiliza¬ 
tion. 


c. )  Survivability.  The  survivability  requirements  fall  into  two  areas, 
namely,  redundancy  and  fault  tolerance.  In  addition,  survivability 
should  be  looked  at  from  two  separate  perspectives:  having  a  high 
probability  of  maintaining  mission  critical  capabilities  with  lim¬ 
ited  weapon  system  damage  (this  is  often  carried  to  extremes  where 
non-flight  safety  capabilities  are  attempted  to  be  maintained  in  the 
presence  of  damage  that  would  not  let  the  aircraft  fly),  and  main¬ 
taining  safety  of  flight  critical  functions  to  the  maximum  extent 
possible. 


(e)  Efficient  hardware  utilization  is  not  in  conflict  with  fault 
tolerance  but  is  opposed  to  redundancy.  Efficient  hardware 
utilization  can  be  achieved  if  redundancy  is  required  only 
where  it  is  necessary.  Redundancy  for  safety  of  flight  criti¬ 
cal  functions  is  considered  an  absolute  requirement.  Redun¬ 
dancy  for  any  other  purpose  should  not  be  incorporated  unless 
justified  in  detail. 


© 


Minimizing  interconnect  requirements  is  not  in  conflict  with 
redundancy  once  redundancy  Is  required.  Fault  tolerance  and 
minimizing  interconnects  are,  however,  in  conflict.  Fault  tol- 
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eratice  cannot  make  a  fault  go  away;  redundancy  does  that.  The 
impact  of  faults  can  be  minimized  by  partial  replacement  of 
functions  by  other  assets  (a  form  of  redundancy),  but  normally 
this  requires  additional  interconnects  to  facilitate  the  as¬ 
sumption  of  tasks.  Additional  interconnects  to  facilitate  par¬ 
tial  replacements  of  functions  should  only  be  incorporated  for 
mission  critical  capabilities  and  only  when  the  partial  func¬ 
tion  replacement  allows  performance  of  the  mission  critical 
capability. 

Simple  control  and  display  does  not  lend  itself  to  either  re¬ 
dundancy  or  fault  tolerance.  Loss  of  prime  capability  and  re¬ 
duced  capability  affected  by  fault  tolerance  features  must  be 
reported  but  can  result  in  cluttered  displays.  Requirements 
for  redundancy  in  the  displays  and  controls  further  complicate 
the  problem  of  simplifying  the  crew  interfaces.  Multiple  dis¬ 
plays  and  controls  for  the  same  purpose  are  at  times  confusing. 
Limitations  on  redundancy  requirements  can  minimize  the  problem 
but  the  problem  still  exists.  Use  of  degraded  mode  backup  as 
opposed  to  redundant  displays  and  controls  (i.e.,  maintenance 
of  critical  capability  via  deletion  of  a  noncritical  capabil¬ 
ity)  is  a  useful  solution  as  long  as  multifunction  devices  are 
utilized  and  they  appear  the  same  for  the  critical  functions  in 
the  degraded  mode.  Use  of  compatible,  if  not  identical,  dis¬ 
plays  and  controls  for  all  crew  stations  allcws  transfer  of  an 
entire  function  to  another  crew  member  and  is  an  effective 
means  of  obtaining  redundant  capability.  The  requirements  for 
true  redundant  system  display  and  control  can  only  be  intelli¬ 
gently  resolved  on  a  control  by  control,  display  by  display 
basis.  Fault  tolerance  display  and  control  issues  also  require 
individual  resolution. 
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d. )  Maximum  Commonality  Is  desirable  in  any  architecture  because  it  sim¬ 
plifies  the  constraints  on  the  architecture  but  it  has  impact  in 
several  areas. 


© 


Sufficient  throughput  capability  for  the  worst  case  application 
leads  to  excess  capability  for  the  remainder  of  applications 
when  common  elements  among  platforms  are  used.  Whenever  pos¬ 
sible,  peaks  in  throughput  requirements  should  be  handled  by 
parallel  capabilities  of  common  elements.  This  approach  leads 
to  some  inefficiencies,  but  should  be  utilized  to  the  maximum 
extent  possible  because  it  has  inherent  growth  capability. 


Multiple  platform  applications  necessitate  satisfying  peculiar 
requrements  or  there  would  be  no  need  for  nultiple  platforms. 
Significant  potential  exists  for  maximizing  commonality  in  new¬ 
ly  developed  platforms.  An  architecture  that  capitalizes  on 
commonality  is  difficult  to  Incorporate  in  existing  platforms 
unless  the  existing  hardware  is  used  as  the  common  element. 
Accommodating  existing  platforms  is  perhaps  best  handled  by 
modularizing  all  input/ output  (I/O)  elements  within  the  archi¬ 
tecture  and  allowing  for  variants  for  existing  platforms. 


© 


The  procurement  of  subsystems  is  severely  complicated  by  com¬ 
monality  with  other  subsystem  constraints.  Procurements  can 
state  "how"  or  "what."  Typically,  they  say  "what,”  at  least 
for  the  initial  procurement.  Enforcing  commonality  requires 
some  "how"  along  with  the  "what"  in  procurement.  GFE  of  common 
elements  is  possible  but  complicates  procurement  and  accounta¬ 
bility  of  the  contractor.  In  addition,  the  elements  must  exist 
for  GFE  which  requires  serial  rather  than  parallel  procure¬ 
ments. 
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e. )  Efficient  Hardware  Utilization  implies  that  IE  one  piece  of  hardware 
can  perform  the  same  function  for  two  elements  of  the  weapon  system, 
then  it  is  assigned  the  tasks. 


© 


The  equipment  Interfaces  necessary  for  efficient  hardware  util¬ 
ization  often  increase  the  interconnect  requirements  to  accom¬ 
modate  the  sharing  of  resources.  In  general,  the  highest  cost 
benefit  is  achieved  by  maximizing  the  hardware  utilization. 


© 


Red/Black  requirements,  in  some  cases,  prevent  one  piece  of 
hardware  from  doing  two  things,  but  the  requirements  must  be 
adhered  to.  However,  the  architecture  should  arrange  Red/Black 
signal  distribution  to  allow  maximum  hardware  utilization. 


f.)  Minimizes  Interconnect  Requirements.  Minimizing  interconnects  sa”®s 
cost,  weight,  and  maintenance,  and  increases  survivability  and  re  - 
ability. 


( nT)  Allowances  for  growth  involve  providing  for  the  unknown.  If 
interfaces  are  minimized,  the  probability  that  the  interface 
that  is  required  for  growth  exists  is  diminished.  One  approach 
that  may  actually  minimize  interconnects  is  to  collect  all  in¬ 
formation  at  a  central  location.  This  approach,  works  only 
when  the  timing  of  the  information  is  not  critical,  and  can 
have  a  severe  influence  on  throughput  and  survivability.  There 
is  no  optimal  solution  for  resolving  the  conflict  between 
growth  and  Interconnects,  but  standardized  general  purpose  in¬ 
puts  and  outputs  offer  the  most  growth  potential. 

g. )  No  Superfluous  Redundancy.  Excessive  redundancy  is  very  attractive 
to  architectural  design,  since  it  is  compatible  with  growth  and  pro¬ 
vides  sufficient  throughput  (i.e.,  the  excess  can  be  used  later  or 
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in  special  cases  since  there  is  no  real  requirement  for  redundancy). 
Unfortunately,  once  something  is  labeled  redundant,  it  is  very  dif¬ 
ficult  to  remove  the  label  to  capitalize  on  the  capability.  If  re¬ 
dundancy  is  not  required,  it  should  not  be  added. 

h.  )  Sufficient  Throughput  Capability  is  self-explanatory,  except  in  the 

definition  of  sufficient.  No  valid  architecture  should  ever  reach 
the  maximum  throughput  limit,  but  how  much  excess  should  there  be? 

An  arbitrary  answer  is  10%  for  the  known  worst  case  requirement  when 
all  potential  platforms  are  considered. 

i.  )  Applicability  to  Multiple  Platforms.  For  a  generalized  architec¬ 

tural  concept  to  be  of  value,  it  must  be  applicable  to  at  least  two 
and  preferably  all  platforms. 

j.  )  Compatibility  with  Red/Black  Requirements  is  not  considered  a  nego¬ 

tiable  area. 

k.  )  Simplified  Control  and  Display  is  a  very  difficult  area  in  which  to 

achieve  a  self-explanatory  requirement.  However,  if  the  control  and 
display  is  not  sufficiently  clear,  the  capabilities  designed  into 
the  architecture  will  probably  never  be  used. 

l. )  Compatible  with  Procurement.  If  the  architecture  does  not  allow  for 

subsystem  performance  specifications  to  be  written  and  tested,  then 
the  architecture  cannot  be  implemented.  This  is  a  major  considera¬ 
tion  that  must  be  included  in  the  architecture. 

ra. )  Allows  Growth.  Compliance  with  this  requirement  should  be  met  in 
the  sense  of  growth  with  no  modification  to  existing  elements  when¬ 
ever  possible. 
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3.2  RESULTS  OF  CONFLICTING  REQUIREMENTS  ANALYSIS 

The  conflict  resolutions  discussed  above  did  not  resolve  the  conflicts  at 
all,  but  they  did  constrain  some  of  the  architectural  considerations.  More 
questions  were  asked  than  were  answered  and  more  "don'ts"  than  "do's”  were 
generated,  but  some  guidelines  are  clear,  viz.: 

o  Specialized  subsystem  survivability  considered  only  at  interface 
o  Commonality  only  among  architectural  members 

o  Specialized  subsystems  should  have  some  functions  done  for  them 
within  the  architecture 

o  Require  redundancy  only  when  actually  necessary 

o  Additional  interconnects  for  fault  tolerance  only  for  mission  criti¬ 
cal  functions 

o  Modularized  I/O  can  help  incorporation  in  existing  platforms 
o  Throughput  should  be  expandable  in  a  parallel  fashion 
o  Red/Black  requirements  should  not  be  compromised 
o  Use  general  purpose  interconnects  to  the  maximum  extent  possible 

o  Maintain  at  least  10%  reserve  throughput  capability. 

4.0  ARCHITECTURAL  DESIGN 


The  design  of  an  aircraft  avionics  architecture  is  highly  dependent  on 
the  mission  requirements  of  the  weapon  system.  This  is  true  primarily  because 
of  the  level  of  subsystem  integration  necessary  to  achieve  overall  weapon  sys¬ 
tem  capability  within  size,  weight  and  cost  constraints.  In  modern  Naval  air¬ 
craft  the  extent  of  subsystem  integration  required  has,  for  all  practical  pur¬ 
poses,  obliterated  the  meaning  of  the  word  system.  A  function  i3  performed  by 
a  group  of  subsystems  none  of  which  exist  solely  for  the  performance  of  that 
function,  e.g.,  a  bombing  system  is  made  up  of  an  ordnance  subsystem,  a  radar 
subsystem,  a  display  and  control  subsystem,  a  navigation  subsystem,  a  communi¬ 
cations  subsystem,  and  the  flight  control  subsystem,  all  of  which  are  used  to 
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perform  other  functions  (make  up  other  systems).  The  mix  of  equipment  types 
and  the  integration  requirements  vary  by  aircraft  mission,  however,  certain 
functional  elements  are  required  for  all  aircraft.  The  basic  requirements  for 
the  functional  elements  that  are  common  between  aircraft  (core  avionics)  dif¬ 
fer  only  in  the  integration  requirements. 

Partially  to  accommodate  the  Integration  requirements  of  different  air¬ 
craft  a  variety  of  similar  but  different  core  avionics  equipment  that  have  the 
same  basic  functional  requirements  have  been  developed.  By  considering  the 
realities  of  the  systems  integration  requirements  in  the  design  of  core  avion¬ 
ics  equipment,  functional  commonality  between  aircraft  types  can  be  achieved 
without  limiting  the  weapon  system  avionics  architecture  design. 

In  order  to  investigate  the  integration  requirements  of  avionics  equip¬ 
ment,  a  multiplatform  avionics  architecture  that  addresses  only  core  avionics 
equipment  was  generated  as  part  of  this  study.  The  architecture  is  not  in¬ 
tended  as  a  blueprint  for  future  aircraft  but  it  does  serve  several  purposes: 

a.  The  model  generated  attempts  to  demonstrate  a  method  of  incorpora¬ 
ting  the  general  architectural  requirements  discussed  in  Section  3.0 
while  maintaining  the  capability  of  accommodating  the  variable  inte¬ 
gration  requirements  of  each  of  the  platforms. 

b.  The  architecture  attempts  to  provide  a  mechanism  whereby  existing 
equipment  can  be  accommodated  in  future  weapon  systems. 

c.  The  architecture  separates  performance  requirements  of  individual 
subsystems  to  the  maximum  extent  practical  in  order  to  show  how  the 
orderly  incorporation  of  improvements  which  are  corapatable  with 
procurement  and  test  requirements  can  be  accomplished. 
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d.  The  architecture  demonstrates  a  means  of  accommodating  the  trans¬ 
plantation  of  new  developments  In  Integrated  subsystems. 

e.  In  addition,  the  architecture  highlights  those  areas  where,  for  re 
liability  reasons  or  because  of  additional  requirements  on  the  sub 
system,  the  subsystem  integration  efforts  will  require  some  varia¬ 
tions  between  platforms. 

4.1  CORE  AVIONICS  SUBSYSTEMS 

The  subsystems  considered  as  core  avionics  are: 

o  Flight  Control 

Dynamics  Sensors 

-  ACLS  (Automatic  Carrier  Landing  System) 

o  Flight  Instrumentation 

Velocity 
Attitude 

-  Altitude 
Heading 

o  Navigation 

Inertial  Navigation 

TACAN  (Tactical  Air  Navigation) 

ADF  (Automatic  Direction  Finding) 

o  Comnunications 

VHF/UHF  (Very  High  Frequency /Ultra  High  Frequency)  Voice 
UHF  Data 
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ICS  (Intercommunications  System) 

IFF  (Identification  Friend  or  Foe) 

o  Displays  and  Controls 

There  are  a  number  of  subsystems  that  were  excluded  from  this  list  be¬ 
cause  of  a  lack  of  universal  applicability  (e.g.,  HF  (High  Frequency)  communi¬ 
cations,  LORAN  (Long  Range  Aid  to  Navigation),  Doppler  Navigation).  There  are 
also  several  subsystems  that  are  not  universally  applicable  (e.g.,  the  Radar 
Beacon  and  the  ILS  (Instrument  Landing  System)  components  of  ACLS )  that  were 
included  because  of  universal  applicability  to  CV  (Aircraft  Carrier) 
operations. 

4.2  SAFETY  OF  FLIGHT  REQUIREMENTS 

The  Mission  Essential  Subsystem  Matricies  (MESM's)  of  reference  k  were 
examined  for  the  A-6E,  F-14A,  F/TF/A-I8,  and  P-3C  weapon  systems.  For  the 
core  avionics  subsystems  in  4.1  the  follcwing  requirements  for  safety  of 
flight  were  determined. 

o  Redundancy  for: 

Flight  Control  System  Components 
Flight  Instrumentation 
Intercommunications 

o  Backup  capability 

Redundant  UHF  or  VHF  backup  for  UHF 
TACAN  with  ADF  as  backup 

4.3  MULTIPLATFORM  AVIONICS  ARCHITECTURE 

The  raultiplatforra  avionics  architecture  developed  for  the  core  avionics 
subsystems  is  shown  in  Figure  1  (provided  as  a  foldout  at  the  end  of  this 
report).  The  architecture  is  to  a  large  extent  based  on  utilizing  existing 
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equipment  types.  The  Control  and  Display  Subsystem  is  based  on  the  Advanced 
Integrated  Display  System  (AIDS)  and  the  navigation  and  flight  control  sensors 
are  combined  using  an  Integrated  Inertial  Sensor  Assembly  (USA). 

The  architecture  is  applicable  to  the  near  term  procurement  of  a  new 
weapon  system  which  is  the  main  reason  for  reliance  on  existing  equipment 
types.  The  use  of  existing  equipment  types  results  in  substantial  similari¬ 
ties  between  Figure  1  and  the  actual  implementations  in  the  F-14A  and  F/A-18. 
The  rationale  for  using  AIDS  and  USA  concepts  for  a  near  terra  procurement  is 
that  both  the  display  and  control  and  overall  flight  control  subsystems  are 
assumed  to  require  development  for  any  new  weapon  system. 

The  central  element  in  the  architecture  is  the  Mission  Computer.  Redun¬ 
dancy  for  the  Mission  Computer  has  been  assumed,  however,  the  actual  number  of 
computers,  the  functional  allocations  between  the  computers,  and  the  computer 
architecture  will  vary  by  aircraft.  The  Mission  Computer(s)  are  assumed  to  be 
CFE  equipment  (even  though  hardware  and  some  software  modules  may  be  govern¬ 
ment  furnished).  The  Mission  Computer(s)  are  considered  CFE  because  of  the 
differences  in  functions  and  software  required  for  various  platforms.  Because 
the  Mission  Computer(s)  will  require  some  CFE  software,  they  cannot  be  sup¬ 
plied  as  an  entire  functioning  unit  and  are  therefore  not  labeled  as  GFE.  The 
Mission  Computer( s)  is  responsible  for  all  core  avionics  management  functions 
(except  flight  control)  and  as  such  forms  a  central  point  to  which  all  other 
equipment  must  be  interfaced.  The  form  of  interface  with  the  Mission  Compu¬ 
ters  has  been  assumed  to  be  via  time  multiplexing  of  digital  information.  Al¬ 
though  for  clarity  not  illustrated  in  Figure  I,  all  time  multiplex  interfaces 
in  Figure  1  are  assumed  dual  redundant.  Each  of  the  interfaces  represent  com¬ 
posite  signal  flow  paths  and  not  necessarily  individual  wires. 

A  preflight  memory  device  is  recommended  to  load  mission  variables  and 
miscellaneous  information  for  all  subsystems.  This  device  would  be  utilized 
to  load:  crew  option  preferences,  aircraft  configuration,  and  a  priori  data 
(example  preset  radio  frequencies  but  not  code  of  the  day  type  information). 
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Additionally,  tills  device  would  provide  backup  configuration  information  to 
non  volatile  memories  in  individual  subsystems  (example,  last  configuration 
prior  to  a  power  interrupt)  and  a  failure  recording  mechanism  for  GSE. 

Only  those  portions  of  the  flight  control  subsystem  applicable  to  core 
avionics  are  shown  in  Figure  1.  The  flight  control  subsytem  has  been  consi¬ 
dered  CFE  with  the  exception  of  a  few  GFE  elements.  The  GFE  assumed  is  com¬ 
prised  of  inertial  sensors,  flight  director  backup  displays,  and  the  Air  Data 
Computer  with  backup  air  sensor  instrumentation  (.Angle  of  Attack  (AOA),  velo¬ 
city,  and  barometric  altitude  indicators).  This  assumption  was  made  based  on 
the  differences  in  basic  flight  control  requirements  for  various  weapons  sys¬ 
tems. 


Subsystem  on/off  power  control  and  advisory  warning  displays  have  been 
assumed  to  be  CFE.  The  incorporation  of  a  central  clock  for  distribution  to 
all  mission  computer  digital  interface  elements  Is  recommended  (see  6. 1.2.2 
and  6. 4. 2. 4).  The  antenna  assets  for  comtrunications  and  navigation  equipment 
are  routed  by  GFE  equipment  recommended  in  6. 4. 2. 2.  The  salient  features  of 
the  other  major  components  are  described  in  the  following  paragraphs. 

4.3.1  Existing  Equipment 

A  heavy  dependence  on  the  use  of  existing  equipment  types  for  the  config¬ 
uration  in  Figure  1  serves  two  purposes,  namely,  allowance  for  time  phasing  of 
Individual  AVCS  equipment  and  a  gradual  build  up  of  equipment  compatable  with 
the  Tactical  Information  Exchange  System  (TIES)  concept. 

Based  solely  on  cost  considerations  it  has  been  assumed  that  Improvements 
for  functional  commonality  of  Naval  avionics  equipment  will  take  place  In  an 
evolutionary  manner.  In  order  to  Impact  any  new  weapon  system  the  majority  of 
equipment  supplied  as  GFE  will  have  to  be  "off  the  shelf"  at  the  time  the 
weapons  system  is  defined.  The  AVCS  program  Is  attempting  to  stock  the 
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shelves  so  this  can  happen  in  a  manner  that  will  result  In  the  use  of  common 
units  among  platforms.  Up  until  the  time  that  all  applicable  GFE  equipment 
becomes  AVCS  design  compatable,  equipment  in  the  inventory  now  should  be  uti¬ 
lized  as  standard  equipment.  For  this  reason  a  key  element  of  the  architec¬ 
ture  of  Figure  1  is  the  use  of  Avionics  Interface  Units  (AIU's)  which  are  dis¬ 
cussed  in  detail  in  6.4.2. 1.  The  AIU  allows  modular  I/O  for  each  subsystem  to 
accommodate  differences  in  equipment  architectural  comparability  (l.e.,  any 
mix  of  AVCS  or  non-AVCS  equipment  can  be  accommodated)  and  the  future  replace¬ 
ment  of  existing  equipment  in  a  manner  that  does  not  directly  affect  the  way 
the  equipment  is  integrated  into  the  weapon  system  (i.e.  ,  integration  is  ac¬ 
complished  on  the  aircraft  side  of  the  AIU).  The  specific  equipment  items  in 
Figure  1  which  are  interfaced  to  the  AIU's  are  arbitrary.  The  use  of  the  AIU 
for  aircraft  interface  allows  this  arbitrary  selection  of  equipment  as  well  as 
future  change  to  the  equipment  without  affecting  the  overall  architecture  or 
interface  requirements.  For  example,  although  additional  aircraft  interfaces 
will  be  required  for  added  functions,  the  direct  Interface  of  Joint  Tactical 
Information  Distribution  System  (JTIDS)  equipment  would  be  accomplished  by  re¬ 
placing  the  AIU  TACAN  module.  Similarly,  replacement  of  the  ARA-63  ILS 
function  by  the  Multimode  Receiver  (MMR)  would  require  only  an  AIU  interface 
module  change. 

The  rationale  for  using  two  or  more  AIU's  Is  to  achieve  redundancy  where 
it  is  needed  and  eliminate  superfluous  redundancy.  This  is  done  by  interfac¬ 
ing  redundant  assets  to  different  AIU's  while  utilizing  only  one  AIU  for  non- 
redundant  assets. 

Equipment  Incorporating  the  standarldzed  interfaces  recommended  in  fol¬ 
lowing  sections  should  minimize  the  signal  conditioning  requirements  for  each 
equipment  AIU  module  and  allow  common  AIU  modules  between  aircraft  in  the  fu¬ 
ture.  In  the  ideal  case  the  AIU's  could  be  completely  eliminated,  however, 
this  is  not  the  likely  case  because  of  differences  between  aircraft.  Assuming 
the  AIU's  will  not  eventually  be  eliminated,  they  are  capable  of  providing: 
buffer  and  distribution  of  clock  signals  and  aircraft  spatial  orientation 
information,  bus  couplers  and  terminations,  blanking  signal  logic  and  distri¬ 
bution;  and  general  equipment  Interconnects. 


18 


Report  Mo.  NADC  81235-20 


Existing  equipment  is  also  assumed  to  be  utilized  for  backup  Attitude 
Reference  Indicator  (ARI)  or  Attitude  Direction  Indicator  (.ADI)  and  Horizontal 
Situation  Indicator  (HSl)  or  Bearing  Distance  Heading  Indicator  (BDHI)  dis¬ 
plays. 

4.3.2  AIDS  Concept  Equipment 

The  architecture  of  Figure  1  uses  the  AIDS  control  and  display  concept 
for  all  core  avionics  subsystem  functions  except  subsystem  power  on/off  con¬ 
trol  and  Intercomnunlcations  subsystem  control.  The  AIDS  equipment  in  Figure 
1  is  comprised  of:  the  two  control  and  display  processors;  the  primary  dis¬ 
plays;  the  avionics  controls;  and  the  voice  recognition  element.  The  clock  is 
also  assumed  part  of  the  display  and  control  subsystem.  Only  core  avionics 
subsystems  are  considered  in  Figure  1  however,  it  has  been  assumed  that  the 
display  and  control  subsystem  provides  for  the  requirements  of  all  avionics 
equipment  (including  mission  equipment).  Certain  controls  for  the  weapons 
control  and  flight  control  subsystems  are  excluded  because  of  their  peculiar 
safety  requirements. 

The  prime  coranunications  medium  between  the  display  and  control  subsystem 
and  the  avionics  is  a  dual  redundant  time  multiplex  bus  interfaced  via  the 
Mission  Computer(s).  In  order  to  preclude  the  necessity  for  separate  power 
supplies  for  the  bus  interfaces  in  the  elements  to  be  controlled,  individual 
power  on/off  controls  for  each  subsystem  including  the  display  and  control 
subsystem  are  suggested.  The  individual  power  controls  also  allcw  manual  con¬ 
trol  of  elements  in  the  case  of  failures  (particularly  for  bus  interface  fail¬ 
ures).  For  parallel  redundant  elements  an  individual  power  control  for  each 
element  that  will  allow  override  shutdown  of  a  failed  element  is  recommended. 

It  has  been  assumed  that  due  to  space  limitations,  there  will  be  no  re¬ 
dundant  control  panels  for  cockpit  display  and  control.  In  order  to  provide 
backup  for  controls,  the  use  of  a  voice  recognition  device  is  proposed.  The 
voice  recognition  device  requires  interface  with  the  ICS  which  makes  the  ICS 
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part  of  the  backup  path  for  avionics  control,  hence,  the  control  of  the  ICS 
via  the  display  and  control  subsystem  is  inadvisable.  For  this  reason,  it  is 
recommended  that  the  ICS  have  separate  redundant  controls.  This  impleraenta- 
|  tion  is  also  consistent  with  the  safety  of  flight  requirements  of  4.2,  par¬ 

ticularly  since  the  ICS  requires  redundancy  and  is  a  necessary  element  in  the 
|  operation  of  UHF  and/or  VHF  coranunications. 

The  AIDS  concept  provides  both  simplified  and  redundant/backup  control 
!  and  display  for  avionics  equipment.  The  concept  utilizes  multifunction  dis¬ 

plays  and  nultipurpose  control  panels.  The  requirements  for  wiring  through 
cockpit  pressure  bulkheads  are  minimized  by  utilizing  both  time  and  frequency 
multiplex  bus  interfaces.  All  display  and  control  processing  is  performed 
within  the  subsystem  by  dual  redundant  processors.  Interface  with  avionics 
subsystems  is  accomplished  via  the  same  frequency  multiplex  bus  used  for  cock¬ 
pit  displays  and  via  the  mission  avionics  time  multiplex  bus.  Interface  with¬ 
in  the  cockpit  (e.g.,  throttle  and  stick  controls)  are  provided  via  discrete 
inputs  to  the  multipurpose  control  panels.  Avionics  to  crew  interfaces  are 
provided  by  combinations  of  multipurpose  television  displays,  a  dot  matrix 
display,  a  Heads  Up  Display,  a  Helmet  Mounted  Display,  programmable  legend 
switches,  and  a  voice  recognition  element. 

The  display  and  control  interface  in  Figure  1  differs  from  the  configura¬ 
tion  in  the  AIDS  System  Specification  (reference  h).  The  system  load  device 
interfaces  with  the  Mission  ComputerC s )  in  order  to  facilitate  the  load  of 
mission  variables  for  all  subsystems  by  one  device  (in  the  AIDS  System  Speci- 
|  fication,  the  load  device  is  interfaced  directly  to  the  display  processor), 

I  however,  control  of  the  operation  of  the  system  load  device  is  through  the 

display  and  control  subsystem.  The  Interface  between  the  Mission  Computer(s) 

|  and  the  display  processor  utilizes  an  augmented  MIL-STD-1553  time  multiplex 

bus  (see  5. 3. 1.3)  along  with  an  external  clock  input  in  order  to  increase  the 
data  transmission  capability  to  the  displays.  The  external  clock  (recommended 
in  6. 4. 2. 4)  is  assumed  part  of  the  Display  and  Control  Subsystem  and  would 
also  provide  time  of  day  readout.  The  frequency  multiplex  bus  is  a  two  wire 
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bidirectional  bus  (see  5. 3. 2. 2)  with  frequency  assignments  established  through 
the  Mission  Computer(s)  in  order  to  allow  compatibility  with  other  frequency 
multiplex  bus  users.  For  safety  of  flight,  provisions  for  discrete  warning 
lights  Independent  of  the  display  and  control  subsystem  are  Incorporated.  The 
display  processor  should  be  capable  of  alphanumeric  indications  of  voice  com¬ 
mands  via  the  cockpit  display  in  the  event  of  a  multipurpose  control  panel 
failure.  It  is  recommended  that  a  manual  ENTER  function,  independent  of  the 
multipurpose  control  panel,  be  incorporated  with  the  voice  recognition  element 
for  backup  operation.  The  voice  recognition  unit  is  shown  interfaced  with  the 
Red  side  of  the  ICS  hence  this  unit  must  meet  TEMPEST  requirements.  Interface 
with  the  Black  side  of  the  ICS  would  only  be  practical  if  the  unit  is  of  a 
type  that  can  be  taught  in  both  plain  and  cipher  mode  as  part  of  the  preflight 
procedure. 

The  AIDS  concept  equipment  forms  a  key  element  in  the  core  avionics  arch¬ 
itecture  considered  in  this  report.  This  display  and  control  concept  is  fund¬ 
amental  to  the  architecture  because  of  the  ability  to  provide  a  consolidated, 
simple,  redundant  form  of  coranunication  between  the  crew  and  the  avionics. 
Because  of  the  dependence  of  other  interfaces  on  the  display  and  control  sub¬ 
system,  this  equipment  is  a  prime  candidate  for  GFE.  Cockpit  display  and  con¬ 
trol  has  traditionally  been  under  contractor  control  because  of  human  factors 
considerations.  A  reversal  of  this  approach  is  not  recommended,  however,  the 
required  use  of  some  GFE  for  cockpit  equipment  is  recommended.  The  basic  AIDS 
equipment  design,  along  with  the  incorporation  of  sufficient  display  process¬ 
ing  capability  and  the  recommended  revisions  of  some  interfaces,  will  allow 
the  flexibility  for  the  airframe  contractor  to  utilize  common  GFE  both  in  the 
cockpit  and  for  other  crew  station  controls  and  displays.  Contractor  utiliza¬ 
tion  of  the  GFE  controls  and  displays  will  require  aircraft  peculiar  software. 
It  is  recommended  that  during  AIDS  development  software  applicable  to  more 
than  one  platform  be  modularized  and  provided  as  Government  Furnished  Software 
(GFS). 
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4.3.3  USA  Concept  Equipment 

The  architecture  of  Figure  1  shows  the  USA's  interfaced  directly  to  the 
Flight  Control  computers.  The  sensors  provide  continuous  updates  of  attitude 
and  acceleration  information  to  each  Flight  Control  computer  for  control  of 
aircraft  trajectory.  The  IISA  navigation  outputs  are  interfaced  directly  to 
Navigation  Processors  which  provide  processed  inertial  navigation  information 
to  the  Mission  Computer(s). 

In  the  initial  generation  of  the  architecture  of  Figure  1,  all  IISA  sen¬ 
sor  interfaces  were  via  the  AIU.  This  interface  would  have  allowed  sampling 
of  attitude  and  rate  information  for  direct  use  by  other  avionics.  Attitude 
and/or  rate  information  is  required  for  sensor  stabilization,  relative  naviga¬ 
tion  calculations,  direction  finding  corrections,  antenna  polarization  con¬ 
trol,  and  data  quality  checks  for  imaging  systems.  This  approach  was  aban¬ 
doned  for  several  reasons: 

a.  The  information  from  the  IISA  sensors  required  by  other  avionics  is 
derivable  from  the  IISA  navigation  outputs  Independent  of  the  flight 
control  outputs.  The  navigation  output  information  requires  coordi¬ 
nate  transformation  for  utilization  by  other  subsystems,  although 
this  function  could  be  performed  within  the  AIU,  its  inclusion  would 
be  opposed  to  the  intended  simplicity  of  the  AIU. 

b.  The  safety  of  flight  considerations  for  flight  control  incorporated 
within  the  IISA  requires  the  incorporation  of  redundancy  and  strict 
control  of  the  processing  of  redundant  Information  in  order  to  main¬ 
tain  capability  in  the  presence  of  multiple  failures.  This  control 
function  requires  a  dedicated  processor  to  provide  immediate  error 
detection.  The  inclusion  of  a  dedicated  processor  within  the  AIU  is 
not  justified  particularly  when  the  processing  requirements  may  vary 
by  aircraft  type  because  of  aerodynamic  performance  as  well  as  sen¬ 
sor  location. 
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c.  A  direct  USA  interface  with  only  the  AIU  would  require  an  AIU  in¬ 
terface  with  the  Flight  Control  Computer.  Thus,  the  AIU  would  be  an 
element  in  series  with  the  flight  control  subsystem.  An  analysis  of 
the  reliability  impact  of  adding  series  elements  to  a  redundant  sys¬ 
tem  was  performed  and  is  presented  in  Appendix  A.  This  analysis 
shows  the  significance  of  the  impact  on  reliability  due  to  the  addi¬ 
tion  of  series  elements  to  a  redundant  subsystem.  The  significance 
of  the  impact  to  the  flight  control  subsystem,  is  increased  by  the 
fact  that  the  subsystem  is  composed  of  only  a  few  elements  and  the 
relationship  between  aircraft  maintenance  periods  and  the  high  re¬ 
liability  elements  that  are  required  for  flight  control  as  is  shown 
in  Appendix  A. 

The  reliability  considerations  are  the  main  reason  for  not  Interfacing 
the  USA  flight  control  outputs  with  the  AIU.  The  same  considerations  lead  to 
the  recommendation  that  the  USA's  be  interfaced  directly  to  the  Flight  Con¬ 
trol  Computer.  The  sensor  assemblies  are  good  candidates  for  GFE,  however,  it 
is  considered  necessary  that  the  Flight  Control  Computer  be  CFE.  The  assumed 
necessity  for  a  CFE  Flight  Control  Computer  is  based  primarily  on  variations 
between  aircraft  aerodynamic  surface  control  requirements,  but  does  not  pre¬ 
clude  use  of  GFE  hardware  for  the  flight  control  computer.  Although  the 
Flight  Control  Computer  software  requirements  must  vary  by  aircraft  type,  it 
is  recommended  that  during  the  USA  development  program,  software  applicable 
to  more  than  one  platform  by  modularized  and  provided  as  future  GFS. 

The  redundancy  considerations  for  the  processing  of  USA  flight  control 
information  do  not  apply  to  the  inertial  navigation  information.  The  Carrier 
Aircraft  Inertial  Navigation  System  (CAINS  II)  uses  sensor  technology  similar 
to  that  of  USA  only  for  navigation  information  processing  (i.e.,  CAINS  II 
sensors  are  not  used  for  flight  control).  The  CAINS  II  is  to  replace  the 
AN/ASN-92  GFE  inertial  navigation  system.  It  has  been  assumed  that  future 
platforms  will  utilize  the  USA  attitude  and  acceleration  measurements  for 
both  flight  control  and  inertial  navigation,  hence,  CAINS  II  will  not  be  re- 
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quired  on  future  platforms.  The  processing  of  IISA  navigation  information  has 
been  postulated  to  be  by  separate  redundant  Navigation  Processors,  however, 
the  processing  should  be  limited  to  the  conditioning  of  sensor  information  for 
subsequent  use  by  the  Mission  Computer(s)  in  geonavigation  computations.  The 
processed  navigation  information  is  provided  to  the  Mission  Computer(s)  via 
the  dual  redundant  time  multiplex  bus  for  correlation  with  other  navigation 
information  and  position  and  course  computations.  The  redundancy  for  inertial 
navigation  is  a  fallout  from  the  use  of  redundant  flight  control  sensors  which 
are  capable  of  providing  navigation  quality  information,  however,  the  use  of 
redundant  Navigation  Processors  (which  could  be  incorporated  in  the  USA's 
without  impacting  the  reliability  of  the  flight  control  subsystem)  can  only  be 
justified  if  they  are  limited  in  capability. 

The  spatial  orientation  information  used  for  inertial  naviagation  is  also 
required  by  other  subsystems  (e.g.,  antenna  stabilization).  The  orientation 
information  desired  by  other  subsystems  are  ground  track  velocity,  local  alti¬ 
tude,  drift  angle  (difference  between  heading  and  ground  track),  pitch  angle 
relative  to  an  earth  stabilized  platform,  roll  angle  relative  to  the  aircraft 
pitch  plane,  roll  rate,  and  heading  rate.  In  the  architecture  of  Figure  1  it 
has  been  assumed  that  all  this  information  is  obtainable  from  the  Mission  Com¬ 
puters),  however,  the  only  mechanism  provided  to  extract  this  information 
from  the  Mission  Computer(s)  is  via  a  time  multiplex  interface.  Considering 
parameter  rate  of  change,  the  sampling  of  velocity,  altitude,  drift  angle,  and 
heading  rate  can  be  accomplished  via  this  interface.  For  highly  dynamic  para¬ 
meters,  this  interface  is  inadaquate  because  of  information  delays.  For  this 
reason  it  is  recommended  that  each  Naviagation  Processor  provide  for  dedicated 
output  of  pitch,  roll,  and  roll  rate  in  a  standardized  aerial  digitial  format. 
In  Figure  1  this  information  is  supplied  from  each  Navigation  Processor  to 
only  one  display  and  control  AIU  interface  module  (ie.,  parallel  not  dual  re¬ 
dundant  connection).  It  is  assumed  that  this  information  will  be  combined 
with  sampled  velocity,  altitude,  drift  angle,  and  heading  rate  Information 
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for  general  distribution.  The  sampled  information  from  the  Mission  Computer 
should  also  contain  information  regarding  the  age  (timeliness)  of  the  data  in 
order  to  allow  its  correct  interpretation  by  the  various  subsystems. 

As  noted  in  the  previous  section,  flight  control  inputs  from  the  crew  are 
not  part  of  the  core  avionics.  Hence,  these  controls  (USA  requires  no  exter¬ 
nal  control)  are  not  part  of  the  core  avionics  architecture.  The  controls  for 
the  processing  of  navigation  information  in  the  Mission  Computer(s)  and  pre¬ 
flight  BIT  of  the  flight  control  subsystem  should  be  part  of  the  core  avionics 
architecture  and  processed  by  the  display  and  control  subsystem. 

The  interfaces  for  processing  flight  control  and  inertial  navigation  in¬ 
formation  from  the  USA's  have  been  assumed  to  be  dedicated  interfaces  because 
of  timing  constraints  and  reliability  considerations. 

In  summary,  the  USA  program  has  little  affect  on  the  core  avionics  arch¬ 
itecture  considered  in  this  report.  This  is  true  since  seperate  flight  con¬ 
trol  and  inertial  sensors  could  provide  the  same  functions,  however,  the  navi¬ 
gation  processor  (e.g.,  CAINS  II)  would  need  to  provide  for  dedicated  spatial 
orientation  information  outputs.  For  reliability  reasons  the  flight  control 
subsystem  is  considered  a  stand  alone  subsystem  with  the  exception  of  pre¬ 
flight  BIT  controls  and  information  displays.  The  inertial  navigation  sub¬ 
system  Is  a  two  level  subsystem  with  sensor  and  first  level  processing  provi¬ 
ded  by  GFE  and  correlation  and  display  controlled  via  the  CFE  Mission  Compu¬ 
ter^).  The  USA  program  is  considered  a  good  opportunity  to  provide  stan¬ 
dardized  GFE  for  attitude  and  acceleration  sensors  as  well  as  some  modularized 
GFS.  The  use  of  limited  capability  GFE  inertial  navigation  processors  is  also 
recommended  in  order  to  provide  mission  equipment  interfaces  and  simplify  pro¬ 
curement  for  the  navigation  quality  sensors.  Despite  the  standalone  nature  of 
this  equipment,  utilization  of  the  standard  interfaces  of  6.2  is  recommended 
for  USA  equipment  in  order  to  provide  for  interaircraft  compatibility. 
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4.3.4  Expansion  to  TIES  Concept 

The  TIES  equipment  concept  is  basically  a  separation  of  "front"  and 
"back"  end  processing  capabilities  for  the  purpose  of  allowing  functional  com¬ 
monality  and  flexabillty  In  the  use  of  assets.  The  concept  utilizes  common 
transmitter  and  receive  assets  as  well  as  common  signal  processing  elements 
arranged  to  provide  maximum  flexabillty  In  the  association  of  transmitter  and 
receiver  assets  with  signal  processing  assets.  The  incorporation  of  the  TIES 
concept  requires  replacement  of  existing  equipment  for  the  functions  to  be 
performed. 

Figure  2  (provided  as  a  foldout  at  the  end  of  this  report)  represents  an 
interum  step  between  the  use  of  dedicated  existing  equipment  and  it's  replace¬ 
ment  by  TIES  eqlupraent.  411  elements  below  the  AIU's  of  Figure  2  are  identi¬ 
cal  to  those  of  Figure  1.  Only  the  radio  coranunications  and  Digital  Data  Link 
(DDL)  assets  above  the  AIU's  have  been  modified  in  Figure  2.  The  axillary  UHF 
radio  has  been  deleted  and  the  "front”  and  "back"  ends  of  the  radio's  and  DDL 
have  been  separated.  (The  ARC-159  used  for  UHF  // 2  in  Figure  1  has  been  re¬ 
placed  In  Figure  2  by  assets  similar  to  ARC-182).  This  separation  allows  use 
of  common  receiver  transmitter  ("front"  end)  hardware  for  both  radios  as  well 
as  for  the  DDL.  The  "back"  ends  for  both  radio's  are  also  common,  however,  a 
separate  signal  processor  for  the  DDL  is  assumed.  The  use  of  an  Intermediate 
Frequency  (IF)  switching  matrix  (see  5.2)  allcws  reconfiguration  of  transmit¬ 
ter  and  processor  assets  to  perform  DDL,  voice,  guard  monitor  and  ADF  with 
fewer  assets  (deleted  ARR-69)  and  more  flexabillty  in  terras  of  fault  toler¬ 
ance.  The  conf iguration  in  Figure  2  is  recommended  as  an  interim  configura¬ 
tion  for  any  near  term  aircraft  avionics  design.  This  recommendation  is  based 
on  the  additional  capability  achieved  with  fewer  assets  as  well  as  compatibil¬ 
ity  with  incorporation  of  the  TIES  concept. 

Figure  3  (provided  as  a  foldout  at  the  end  of  this  report)  is  the  same 
basic  architecture  as  Figure  1  with  TIES  equipment  Incorporated.  All  elements 
below  the  AIU's  of  Figure  3  are  identical  to  those  of  Figures  1  and  2  with  the 
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exception  of  the  mission  computer  time  toiltiplex  bus  interfaces.  In  addition 
to  the  deletion  of  the  auxiliary  UHF  receiver  the  AIU  interfaces  for  VHF/UHF 
'H  and  #2 ,  DDL,  IFF,  TACAN/JTIDS  have  been  deleted  in  Figure  3.  These  func¬ 
tions  will  be  provided  by  TIES  equipment  and  since  AVCS  standardized  inter¬ 
faces  for  TIES  equipment  have  been  assumed  the  AIU  is  not  required  for  direct 
interfaces  associated  with  these  functions.  A  new  AIU  module  for  interface  of 
TIES  equipment  and  the  KIT-1A  would  be  required. 

The  transmitter  receiver  assets  similar  to  ARC-182  assumed  in  Figure  2  as 
well  as  the  antenna  interfaces  for  these  units  remain  identical  for  the  TIES 
incorporation  shown.  The  "back"  ends  for  the  radio  and  DDL  are  replaced  by 
redundant  two  channel  TIES  narrow  band  converters  and  TIES  data  processors. 

The  IFF  and  TACAN  “front"  end  assets  are  replaced  by  TIES  Lx  Band  assets  (a 
single  transmitter  and  a  four  channel  reciever)  with  the  "back"  end  function 
replaced  by  a  non  redundant  wide  band  converter  and  a  JTIDS  wide  band  security 
unit. 


The  IF  switching  network  of  Figure  2  is  replaced  by  frequency  multiplex 
interfaces  with  the  TIES  incorporation.  The  frequency  multiplex  interface 
allows  greater  flexibility  than  the  IF  switch  configuration  (example,  simul¬ 
taneous  transmission  of  one  signal  by  two  transmitters)  and  addition  of  ele¬ 
ments  without  complicating  the  configuration.  In  Figure  3  the  frequency  mul¬ 
tiplex  bus  provides  simultaneous  signal  interface  for  all  VHF/UHF  and  Lx  band 
assets.  In  general,  the  frequency  multiplex  bus  provides  signal  interface  for 
all  TIES  assets  (example  HF)  not  just  those  illustrated  in  Figure  3. 

The  TIES  configuration  in  Figure  3  differs  from  the  current  laboratory 
demonstration  model  of  TIES.  The  frequency  multiplex  bus  in  Figure  3  is  a  two 
wire  bidirectional  bus.  The  TIES  laboratory  bus  is  physically  similar  in  that 
is  two  wire,  however,  signals  are  coupled  on  only  one  wire  depending  on  the 
desired  bus  transmission  direction.  The  bidirectional  two  wire  bus  is  recom¬ 
mended  (as  discussed  in  5.3.2)  to  make  bus  routing  and  equipment  location  in¬ 
dependent  and  for  compatibility  with  the  recommended  AIDS  bus.  The  recom¬ 
mended  bus  is  electrically  different  than  the  TIES  laboratory  bus.  A  redun- 
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dant  frequency  multiplex  bus  configuration  is  utilized  in  Figure  3  with  only 
that  equipment  which  requires  redundancy  (comnunications  related  assets)  hav¬ 
ing  redundant  connections.  Combined  filter  amplifier  assemblies  in  series 
with  the  frequency  multiplex  bus  are  incorporated  for  Red/Black  compatibility 
as  discussed  in  5. 3. 2. 2. 

The  current  TIES  concept  does  not  utilize  antenna  switch  networks  and 
would  place  transmitter  receiver  assets  physically  close  to  the  antennas  to 
decrease  the  transmitter  receiver  requirements  by  eliminating  most  of  the 
coaxial  cable  losses.  The  configuration  shown  in  Figure  3  is  recommended 
because  it:  (a)  is  compatible  with  growth  into  the  TIES  concept,  (b)  would 
not  require  individual  upper/lower  antenna  front  end  assets,  and  (c)  does  not 
require  individual  antennas  to  be  associated  with  each  transrai tter/receiver. 

The  narrow  band  converter  units  in  Figure  3  assume  two  channel  simulta¬ 
neous  capability,  the  TIES  laboratory  equipment  utilizes  one  or  three  channel 
equipment.  The  minimum  capability  recommended  is  two  simultaneous  channels. 
The  Data  Processors  utilized  for  TIES  equipment  should  be  capable  of  providing 
one  redundant  analog  audio  output  for  distribution  by  the  AIU  to  the  ADF  an¬ 
tenna  control  and  the  ICS.  The  redundant  audio  output  for  the  wide  band  con¬ 
verter  data  processor  is  not  required,  however,  identical  hardware  for  the 
data  processors  is  recommended.  A  sidetone  signal  for  voice  transmission  can 
be  provided  synthetically  by  the  TIES  data  processor.  This  eliminates  the 
necessity  for  using  a  second  frequency  multiplex  bus  channel  to  return  the 
audio  from  the  transmitter  receiver  assets,  however,  a  BIT  check  of  the  trans¬ 
mitted  audio  should  be  required  and  allow  the  generation  of  synthetic  side- 
tones  only  when  acceptable  transmission  actually  occurs.  A  nonredundant, 
serial  data  interface  between  the  wideband  data  processor  and  an  AIU  display 
and  control  interface  module  is  also  recommended  to  provide  spatial  orienta¬ 
tion  information  for  JTIDS  relative  navigation  computations.  The  interface 
between  the  data  processor  and  the  display  and  control  module  would  also 
provide  for  deck  edge  digital  data  input  to  the  data  processor. 
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The  Interface  of  TIES  Data  Processors  to  the  Mission  Computer  is  assumed 
to  be  via  the  redundant  augmented  MIL-STD-1553  bus  (the  wide  band  data  proces¬ 
sor  does  not  require  redundant  connection).  The  interface  of  the  TIES  "trans¬ 
mitter  receiver  assets  and  the  Mission  Computer  is  assumed  to  be  via  a  redun¬ 
dant  connection  to  only  the  serial  portion  of  the  mission  computer  bus.  The 
control  interface  for  the  transmitter  receiver  assets  and  the  data  processors 
utilizes  IEEE-488  in  the  laboratory  configuration.  The  1553  configuration  is 
recommended  in  order  to  minimize  the  number  of  interface  types  and  provide 
compatibility.  The  1553  interfaces  would  provide  data  exchange  over  the  aug¬ 
mented  bus  and  controls  including  frequency  multiplex  bus  channel  assignments 
over  the  serial  portion  of  the  augmented  bus. 

The  TIES  concept  offers  a  significant  opportunity  to  achieve  functional 
commonality  while  reducing  the  total  number  of  equipments  yet  providing  redun¬ 
dancy  as  well  as  backup  capability.  The  TIES  concept  also  simplifies  and  re¬ 
duces  the  avionics  architecture  interfaces  (illustrated  by  the  reduced  number 
of  AIU  interface  modules  in  Figure  3).  The  difficulty  of  implementing  the 
TIES  concept  is  that  it  requires  a  complete  revision  of  standard  equipment. 

The  incorporation  of  the  frequency  multiplex  bus  along  with  AIDS  and  the  es¬ 
tablishment  of  TIES  compatible  VHF/UHF  transmitter  receiver  assets  will  great¬ 
ly  relieve  the  impact  of  TIES  incorporation.  It  is  recommended  that  the  IF 
access  to  VHF/UHF  assets  be  incorporated  independent  of  the  TIES  development, 
and  that  a  parallel  development  of  GFE  Lx  band  assets  compatible  with  both  the 
JTIDS  and  the  TIES  equipment  be  pursued.  Additionally,  GFE  development  of 
TIES  signal  processors  is  recommended  to  allow  incorporation  of  the  overall 
TIES  concept  in  future  platforms. 

4.3.5  Compatibility  with  Mission  Equipment 

The  architecture  of  Figures  1-3  does  not  represent  any  weapons  system 
avionics  architecture.  This  is  true  because  of  the  differences  in  require¬ 
ments  for  various  aircraft.  For  utility  and  land  based  aircraft,  additional 
navigation  aids  and  comnunications  subsystems  are  usually  provided.  For  non 
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CV  aircraft  the  ACLS  subsystem  is  not  required  and  inertial  navigation  sub¬ 
systems  are  not  incorporated  in  some  aircraft.  Most  aircraft  carry  a  large 
complement  of  additional  equipment  required  for  the  performance  of  specific 
missions.  For  the  architecture  of  Figures  1-3  to  qualify  as  a  Multiplatform 
Avionics  Architecture  (that  portion  of  the  Weapons  System  Avionics  Architec¬ 
ture  that  is  applicable  to  many  weapons  systems),  it  must  be  compatible  with 
the  variations  required  by  the  individual  weapons  system  configurations. 

With  the  exception  of  the  Mission  Computer(s),  the  Display  and  Control 
subsystems,  and  the  distribution  of  spatial  orientation  information  by  the 
Navigation  Processors,  the  deletion  of  equipment  does  not  affect  the  Multi- 
platform  Avionics  Architecture. 

The  equipment  required  in  addition  to  that  incorporated  in  the  architec¬ 
ture  of  Figures  1-3  must  be  accommodated.  This  equipment  falls  into  several 
categories. 

a.  Supplemental  Core  Avionics  -  Additional  elements  with  functions  sim¬ 
ilar  to  the  core  avionics  functions  are  or  will  be  utilized  in  some 
aircraft,  for  example,  HF  comnunications,  additional  Digital  Data 
Links,  Global  Positioning  System  (GPS),  Doppler  Navigation  or  Cor¬ 
relation  Velocity  Sensor  (CVS),  and  miscellaneous  navigation  aids 
(OMEGA,  LORAN,  Lew  Frequency /Automatic  Direction  Finding  (LF/ADF), 
VHF  Omni  Range  (VOR),  VOR  Localizer  (V0R/L0C),  Marker  Beacon,  and 
Glideslope) . 

b.  Weapons  Control  -  Most  Navy  aircraft  incorporate  a  Weapons  Control 
Subsystem.  These  subsystems  vary  by  aircraft  mission  and  include 
control  functions  for  a  variety  of  ordnance.  The  functions  may  in¬ 
clude  elements  to  provide  flight  control  for  weapons  delivery  or 
ground  controlled  bombing,  laser  trackers  for  weapon  delivery, 

or  sonobuoy  launch  control. 


30 


Report  No.  NADC  81235-20 


c.  Generic  Avionics  -  Many  Navy  aircraft  carry  generic  equipment  for 
the  collection  and  processing  of  information  from  a  non  cooperative 
external  environment.  These  equipment  items  include  Radar  foe  tar¬ 
geting,  weather  avoidance,  and  navigation;  IFF  interrogators;  Elec¬ 
tronic  Warfare  (EW)  Equipment  for  threat  warning,  threat  deception, 
and  target  identification;  and  FLIR  (Forward  Looking  Infrared  Re¬ 
ceiver)  for  targeting  and  threat  identification. 

d.  Specialized  Subsystems  -  Mission  specific  equipment  is  required  in 
specialized  aircraft  for  magnetic  anomaly  detection.  Acoustic  data 
collection  and  processing,  imagery,  target  designation.  Radio  Fre¬ 
quency  (RF)  intelligence  gathering,  standoff  jamming,  and  command 
comnunication  links. 

No  aircraft  requires  all  the  additional  equipment  mentioned  above.  Nor 
could  any  specific  configuration  of  core  avionics  reasonably  accommodate  all 
the  equipment  because  of  the  level  of  integration  required  between  the  core 
and  mission  avionics.  Any  Multiplatform  Avionics  Architecture  mist,  however, 
be  compatible  with  allcwing  adaptations  for  different  configurations  of  the 
mission  equipment  above.  In  general,  the  mission  equipment  requires  integra¬ 
tion  with  the  Display  and  Control  subsystem,  the  Navigation  subsystem,  the 
Mission  Computer(s),  the  Flight  Control  subsystem,  the  ICS,  and  the  Comnunica- 
tions  subsystem  (i.e. ,  virtually  all  the  core  avionics  elements). 

In  the  integration  of  mission  equipment  and  core  avionics,  several  gen¬ 
eral  philosophies  are  recommended. 

o  In  order  to  preclude  the  incorporation  of  excess  capability  (mission 
equipment  peculiar  interfaces)  in  core  avionics  equipment,  the  di¬ 
rect  interface  of  core  avionics  equipment  and  the  mission  equipment 
is  not  recommended.  The  core  to  mission  avionics  interfaces  should 
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be  accommodated  through  AID  interfaces.  An  exception  to  this  recom¬ 
mendation  would  be  for  nultiplex  interfaces  where  information  dis¬ 
tribution  is  controlled  via  the  Mission  Computer( s)  (e.g.,  time  or 
frequency  multiplex  bus). 

o  For  the  purpose  of  achieving  greater  commonality  among  mission  avi¬ 
onics  equipment,  the  standard  interfaces  recommended  for  core  avion¬ 
ics  should  be  utilized  for  mission  equipment  as  well.  The  use  of 
AIU  interface  modules  or  incorporation  of  separate  mission  avionics 
AIU's  for  mission  equipment  is  encouraged  in  order  to  allow  the  sep¬ 
aration  of  aircraft  integration  requirements  ar.d  specific  equipment 
requirements.  The  direct  interface  of  mission  equipment  and  CFE,  as 
opposed  to  an  interface  via  an  AIU,  is  however,  encourged  for  equip¬ 
ment  peculiar  to  a  single  aircraft. 

o  For  the  purpose  of  avoiding  excess  processing  capability,  mission 

equipment  that  operates  primarily  as  a  general  purpose  sensor  (e.g., 
Electronic  Support  Measures  (ESM)  receivers  or  Doppler  Navigation) 
should  be  interfaced  via  an  AIU  with  sensor  capability  on  the  GFE 
side  and  correlation  processing  (e.g.,  Radar  track  and  ESM  correla¬ 
tion  or  dead  reckoning  navigation)  performed  on  the  CFE  side.  This 
recommendation  will  allow  the  CFE  equipment  to  control  the  distribu¬ 
tion  of  sensor  information  and  provide  for  signal  conversion  within 
the  AIU  (e.g.,  synchro  to  digital  conversion  for  distribution  of 
ground  speed  and  drift  angle  from  the  Doppler  Navigation  equipment) 
but  does  not  preclude  GFE  processing  elements  interfaced  to  the  CFE 
side  of  the  AIU  (e.g.,  GFE  ESM/Radar  target  correlator). 

o  Mission  equipment  that  requires  direct  CFE  interface  (e.g.,  fire 

control  radar)  and  interface  to  core  avionics  (e.g.,  blanking  to  and 
from  the  radar  beacon)  should  be  accommodated  via  a  prime  CFE  module 
of  the  AIU  for  access  to  the  core  avionics  interfaces  (e.g.,  display 
and  control  module).  This  recommendation  is  made  to  insure  that 
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differences  in  the  signal  distribution  requirements  among  aircraft 
do  not  require  tailoring  GFE  AIU  modules  to  individual  aircraft  re¬ 
quirements. 

In  order  to  examine  the  compatibility  of  the  architectures  of  Figures  1-3 
with  the  accommodation  of  the  mission  equipment,  some  suggested  methods  of  in¬ 
tegration  have  been  generated  and  are  given  below.  A  variety  of  equipment  was 
examined  to  determine  compatibility  and  not  to  recommend  any  particular  con¬ 
figuration.  A  number  of  navigation  aids  are  included  in  the  examination  to 
accommodate  aircraft  that  may  not  incorporate  inertial  navigation.  The  re¬ 
quirements  for  these  navigation  aids,  in  conjunction  with  the  architecture  of 
Figures  1-3,  should  be  examined  carefully  because  of  the  redundant  inertial 
navigation  capability  assumed  in  Figures  1-3.  For  example,  assuming  judicious 
power  distribution,  realignment  of  one  inertial  subsystem  by  the  redundant 
subsystem  is  possible  even  after  a  power  interrupt,  thus  the  necessity  for  a 
large  number  of  additional  nontactical  navigation  aids  becomes  questionable. 

In  all  cases  (i.e.,  with  or  without  inertial  navigation  capability),  naviga¬ 
tion  equipment  should  separate  the  current  position  sensing  function  and  the 
navigation  processing  to  allcw  processing  for  one  navigation  solution  (course) 
based  on  a  variety  of  position  information  inputs. 

4. 3. 5.1  Supplemental  Core  Avionics 

a.  Communications .  The  incorporation  of  HF  communications  and  addi¬ 
tional  digital  data  links  can  be  accommodated  by  utilizing  AIU  in¬ 
terface  modules  for  the  configurations  of  Figures  1  or  2.  The  AIU 
aircraft  interfaces  allow  direct  access  to  the  Mission  Computer(s) 
and  the  ICS  for  these  equipment  items.  The  IF  switching  matrix  of 
Figure  2  is  compatible  with  these  assets,  assuming  only  one  addi¬ 
tional  IF  interface  is  required.  If  more  than  one  additional  IF  in¬ 
terface  is  required,  the  implementation  of  the  TIES  concept  (Figure 
3),  rather  than  a  more  complex  switching  arrangement,  is  recommend¬ 
ed.  The  implementation  of  the  TIES  concept  could  allow  addition  of 
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only  front  end  assets  for  HF  capability  while  simultaneously  provid¬ 
ing  additional  data  link  capability  via  the  converter  and  data  proc¬ 
essor  assets. 

Civilian  Navigation  Aids.  The  incorporation  of  Very  Low  Frequency 
(VLF )  and  Low  Frequency  (LF)  equipment  (e.g.,  OMEGA,  LORAN,  LF/ADF) 
is  required  in  some  extended  mission  aircraft.  LORAN  is  considered 
a  specialized  subsystem  in  that  it  requires  manual  operation  and, 
because  of  potential  discontinuance  of  service,  will  not  be  con¬ 
sidered  further.  LF/ADF  equipment  is  likewise  considered  a  special¬ 
ized  subsystem.  However,  an  AIU  interface  module  could  be  utilized 
for  control,  and/or  audio  and  display  interfaces  via  the  core  avi¬ 
onics.  For  incorporation  of  OMEGA  navigation,  the  use  of  an  AIU  in¬ 
terface  is  recommended.  However,  only  position  fix  outputs  from  the 
OMEGA  equipment  are  recommended.  Dead  Reckoning  processing  and  way 
point  computations  should  be  processed  by  the  Mission  Computer(s). 

The  incorporation  of  VHF  equipment  (VOR,  V0R/L0C,  Marker  Beacon)  to 
provide  for  compatibility  with  civilian  navigation  aids  and  civilian 
ILS  can  be  accommodated  by  use  of  AIU  interface  modules.  These 
modules  would  convert  display  information  for  routing  to  the  display 
and  control  subsystem  via  the  Mission  Coraputer(s)  or  provide  direct 
interface  to  backup  displays  and  advisory/warning  indicators.  Simi¬ 
larly,  a  UHF  Glideslope  Receiver  can  be  accommodated.  The  equipment 
required  for  civilian  compatibility  is  not  generally  utilized  in 
Navy  aircraft  because  of  the  additional  hardware  required  to  perform 
these  functions. 

Replacement  of  the  ARA-63  by  the  Multimode  Receiver  for  the  ACLS 
function  also  provides  the  capability  for  processing  civilian  ILS 
signals.  The  interfaces  for  the  MMR  civilian  ILS  outputs  would  be 
provided  via  the  ILS  and  Display  and  Control  AIU  interface  modules. 
Access  to  VHF/UHF  antenna  assets  for  the  MMR  is  available  through 
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antenna  switching  unit  spare  inputs  (spares  available  since  both 
units  identical)  although  incorporation  of  a  separate  Marker  Beacon 
antenna  would  be  required.  Compatibility  with  the  Federal  Aviation 
Administration  Microwave  Landing  System  (MLS)  can  be  provided  by  the 
MMR  but  would  also  require  additional  antenna  assets.  With  the  in¬ 
corporation  of  TIES  equipment,  the  majority  of  assets  required  for 
civilian  VOR  and  ILS  are  also  available.  In  Figure  3,  assuming  the 
ARC-182  type  transceiver  is  utilized  for  separate  voice  communica¬ 
tion,  additional  assets  for  processing  either  VOR  or  VOR/LOC  and  UHF 
Glideslope  information  are  provided  by  the  other  two  ARC-182  type 
transceivers.  In  order  to  incorporate  the  Marker  Beacon  signal  an 
additional  VHF  asset  would  be  required.  Since  this  asset  is  provi¬ 
ded  by  the  MMR,  and  the  MMR  will  be  compatible  with  the  MLS,  the 
processing  of  all  civilian  ILS  signals  by  the  MMR  rather  than  the 
TIES  equipment  is  recommended.  However,  if  a  hardware  savings  in 
the  MMR  can  be  achieved  use  of  the  ARC-182  type  assets  by  the  MMR 
should  be  investigated.  The  access  to  the  assets  could  be  provided 
via  the  frequency  multiplex  bus  of  Figure  3.  The  MMR  access  to  the 
VHF/UHF  assets  via  the  IF  switches  of  Figure  2  is  not  recommended 
since  the  addition  of  two  connections  would  overly  complicate  the 
switching  requirement. 

c.  Military  Navigation  Aids.  Doppler  Navigation  and  CVS  equipment  are 
supplemental  core  avionics  but  are  considered  as  mission  equipment 
because  this  capability  is  not  incorporated  in  all  platforms.  In 
the  architecture  of  Figures  1-3,  navigation  computations  are  assumed 
to  be  a  Mission  Computer(s)  function.  A  typical  Doppler  Navigation 
subsystem  measures  ground  speed  plus  drift  angle  and  computes  a  nav¬ 
igation  route.  It  is  recommended  that  this  type  system  be  treated 
as  a  GFE  sensor  interfaced  to  an  AIU  with  processing  provided  on  the 
CFE  side  of  the  AIU.  This  configuration  eliminates  excess  redundant 
processing  capability,  allows  correlation  of  all  navigation  sensor 
information  in  the  processing  element,  and  reduces  the  number  of 
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different  types  of  navigation  display  formats.  It  is  recommended 
that  GPS  equipment  be  interfaced  in  the  same  manner  (i.e.,  a  GFE 
navigation  sensor  interfaced  to  the  AIU  with  navigation  course  in¬ 
formation  processed  in  a  central  navigation  processor  on  the  CFE 
side  of  the  AIU).  JTIDS  is  not  a  navigation  subsystem,  however,  it 
does  perform  relative  navigation  calculations.  The  interface  of 
JTIDS  via  an  AIU  is  recommended  because  of  the  fact  that  JTIDS  com¬ 
munications  and  TACAN  functions  are  part  of  the  core  avionics.  The 
AIU  interface  will  also  allow  aircraft  information  (e.g.,  velocity 
and  altitude  for  relative  navigation  processing)  to  be  provided  to 
GFE  JTIDS  equipment  in  a  standard,  real  time  format  by  the  AIU.  The 
performance  of  relative  navigation  computations  within  the  JTIDS 
equipment  is  justified  since  real  time  computations  are  necessary  in 
order  to  control  message  traffic.  The  computation  for  geonavigation 
within  JTIDS  is  not  recommended  for  the  same  reasons  given  for  Dop¬ 
pler  or  CVS,  and  GPS  (central  processing  for  correlation  and  simpli¬ 
fied  display).  Another  justification  for  not  performing  navigation 
processing  within  JTIDS  or  GPS  is  that  these  equipment  items  eventu¬ 
ally  be  replaced  by  TIES  (extended  Lx-band  capability  for  GPS  in¬ 
corporation)  and  navigation  processing  when  incorporated  in  a 
central  navigation  processor  would  not  have  to  be  replaced.  How¬ 
ever,  if  incorporated  within  JTIDS  and  GPS,  navigation  processing 
within  TIES  would  have  to  be  redeveloped. 

4. 3. 5. 2  Weapons  Control 

The  Weapons  Control  Subsystem  is  not  shown  in  Figures  1-3  since  it  is  as¬ 
sumed  to  have  direct  interface  with  only  the  Mission  Computer(s)  and  Flight 
Control  subsystems  which  are  both  assimed  to  be  CFE  elements.  Display  and 
control,  except  for  controls  with  peculiar  safety  requirements,  would  be  pro¬ 
vided  by  the  display  and  control  subsystem  via  the  Mission  Computer(s). 
Interface  of  the  Weapons  Control  Subsystem  and  other  mission  avionics  would 
either  be  direct  (e.g.,  Sparrow  Illuminator  mode  control)  or  via  the  Mission 
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Computer(s)  (e.g.,  ground  speed  and  drift  angle  from  the  Doppler  Navigation). 
Interface  with  core  avionics  vrould  be  via  the  Mission  Computer(s)  (e.g.,  alti¬ 
tude  or  DDL  information)  except  for  discrete  outputs  from  the  AIU  display  and 
control  Interface  module  which  i6  a  CFE  module  (e.g.  ,  weapon  release  signals 
derived  from  the  DDL  in  ground  control  bombing).  Since  the  Weapons  Control 
Subsystem  is  assumed  to  interface  directly  with  only  CFE  equipment  or  other 
mission  equipment,  the  core  avionics  architecture  of  Figures  1-3  is  assumed 
compatible  with  this  subsystem. 

4. 3. 5. 3  Generic  Avionics 

The  control  and  display  for  Radar,  FLIR,  and  EW  equipment  is  directly 
compatable  with  AIDS  concept  equipment.  Radar  and  FLIR  displays  should  be 
provided  over  the  frequency  multiplex  bus.  EW  equipment  displays  are  symbolic 
and  therefore  can  be  accommodated  under  Mission  Computer(s)  control  over  the 
augmented  time  multiplex  bus  to  the  Control  and  Display  Processor.  The  EW  in¬ 
terface  with  the  augmented  mission  conq>uter  bus  will  facilitate  direct  memory 
transfers  between  equipment  elements  (e.g.,  threat  file  exchange  between  warn¬ 
ing  system  and  jammer)  and  the  loading  of  a  priori  data  from  the  Preflight 
Load  and  Memory  Device.  The  Radar/ IFF  Interrogator  and/or  FLIR  require  only 
connection  to  the  serial  portion  of  the  Mission  Computer  bus  for  control  and 
frequency  multiplex  bus  channel  assignments.  Because  of  potential  uses  for  EW 
video  signals  by  other  subsystems  and  the  necessity  to  continuously  update 
these  equipment  items  due  to  threat  changes,  an  interface  using  an  AIU  module 
is  recommended.  Blanking  signals  would  be  interfaced  through  the  EW  AIU 
modules  and  through  the  display  and  control  Interface  module  for  the  Radar  and 
IFF  interrogator. 

The  instantenous  field  of  view  used  by  Radar  and  FLIR  sensors  requires 
information  about  the  aircraft  spatial  orientation.  In  the  architecture  of 
Figures  1-3  this  Information  is  assumed  available  for  highly  dynamic  parame¬ 
ters  (roll,  pitch,  roll  rate)  from  the  Navigation  Processors,  for  sampled 
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parameters  (velocity,  altitude,  drift  angle,  heading  rate)  in  the  Mission  Com¬ 
puter,  and  in  a  combined  format  from  the  display  and  control  AIU  interface 
modules.  The  recommended  interface  is  through  the  AIU. 

The  recommended  Radar/FLIR  interfaces  are  directly  compatible  with  image 
correlation  processing  in  that  standardized  format  display  information  is 
available  over  the  frequency  multiplex  bus  independant  of  the  display  cur¬ 
rently  presented.  Additionally,  the  Radar/FLIR  sensors  would  operate  utiliz¬ 
ing  the  same  aircraft  spatial  orientation  information.  Electronic  Warfare 
sensor  information  as  well  as  IFF  interrogator  response  information  would  also 
be  available  over  the  time  multiplex  bus  for  additional  correlation  and  target 
identification.  Subsequent  display  of  correlated  information  would  be  accom¬ 
plished  over  the  frequency  multiplex  bus. 

The  interfaces  shown  in  Figures  1-3  for  existing  core  avionics  (items 
above  the  AUI's)  and  the  AIU's  are  dedicated  interfaces.  Multiplex  interfaces 
are  not  required  and  are  not  provided  for  in  the  equipment  shown  (ARC-182  does 
provide  a  1553  interface).  Some  of  the  mission  equipment  recommended  for  AUI 
interfaces  do  require  nultiplex  interfaces.  The  recommended  configuration  for 
some  equipment  (e.g.,  EW  equipment)  interfaces  mission  equipment  directly  to 
the  augmented  mission  computer  time  multiplex  bus.  Other  equipment  (e.g., 
Radar)  are  recommended  to  interface  to  the  serial  portion  of  the  mission  com¬ 
puter  time  multiplex  bus  and  to  the  frequency  multiplex  bus.  Direct  interface 
to  the  mission  computer  time  tailtlplex  bus  is  recommended,  however,  there  are 
problems  with  this  approach.  In  Figure  3  there  are  twenty  terminals  connected 
to  the  mission  computer  bus  which  has  a  maximum  capacity  of  31  addresses,  thus 
there  is  a  limit  to  the  number  of  additional  terminals  that  can  be  utilized. 
Since  existing  equipment  will  also  be  utilized  for  mission  avionics  the  prob¬ 
lem  of  MIL-STD-1553  A  vs  B  arises.  The  resolution  of  how  many  terminals  and 
the  configuration  of  different  types  (A  and  B)  are  assumed  part  of  the  CFE 
Mission  Coraputer(s)  arrangement,  however,  the  Mission  Computer  interfaces  in 
the  AIU's  which  are  also  CFE  can  be  utilized  to  provide  a  buffer  between  A  and 
B  terminals  or  an  extension  of  the  mission  coiqputer  bus. 


38 


Report  No.  NADC  81235-20 


4. 3. 5. 4  Specialized  Subsystems 

As  discussed  in  section  3.0,  the  peculiar  requirements  of  specialized 
subsystems  should  not  be  accommodated  in  a  Multiplatfora  Avionics  Architec¬ 
ture.  The  incorporaton  of  redundant  interfaces  between  vitually  all  equipment 
on  the  CFE  side  of  the  AIU  in  Figures  1-3  and  the  use  of  at  least  two  AIU’s, 
should  provide  adaquate  survivability  considerations  for  specialized  equip¬ 
ment.  The  control  of  time  and  frequency  multiplex  interfaces  by  CFE  equipment 
as  well  as  CFE  software  in  the  display  and  Control  Processor  should  allow  suf¬ 
ficient  flexability  to  incorporate  some  of  the  Specialized  Subsystems  func¬ 
tions  (e.g. ,  display  and  control)  within  the  architecture.  The  use  of  AIU's 
for  distribution  of  blanking  and  aircraft  spatial  orientation  signals  through 
CFE  display  and  control  modules  should  likewise  accommodate  the  specialized 
subsystems . 

5.0  INTERFACES  AND  INTERFACE  REQUIREMENTS 

The  avionics  architectural  design  determines  the  interfaces  between  each 
element  of  a  subsystem  and  all  the  other  elements  of  the  weapon  system.  Re¬ 
ducing  the  Impact  of  implementing  the  interfaces  to. both  the  weapon  system  and 
the  subsystems  in  terms  of  size,  weight,  power,  cooling,  and  complexity  while 
maintaining  commonality,  growth  capability,  and  technology  transparency  is  a 
natural  method  to  achieving  the  goals  of  the  AVCS  program.  To  this  end,  in¬ 
terface  requirements  were  examined  in  some  detail. 

For  avionics  equipment,  the  required  interfaces  fall  into  three  general 
categories. 

a.  Control/Status  Information  -  operating  commands  or  controls,  timing 
or  feedback  information,  status  or  control  outputs. 

b.  Information  Transfer  -  of  either  raw,  partially  processed,  or  di¬ 
rectly  interpretable  data. 
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c.  Resources  -  power  and  cooling. 

The  requirements  for  resource  distribution  were  not  considered  as  part  of 
this  study.  The  types  of  interfaces  required  for  control/s ta^us  and  informa¬ 
tion  transfer  can  be  grouped  as  follows. 

a.  Binary  -  discrete  signals  (on/off,  BIT  command,  light  outputs,  stat¬ 
us  I/O,  timing  signals,  etc.)  where  state  as  a  function  of  time  is 
the  information  conveyed.  Although  grammatically  incorrect  and  not 
recommended  ,  tri-level  signals  (three  logic  states)  would  be  con¬ 
sidered  in  this  category. 

b.  Digital  -  signals  where  the  sequence  of  states  over  a  fixed  period 
of  time  convey  coded  information  (e.g.,  digital  bytes  or  words). 

c .  Analog  -  time  varying  signals  below  20  KHz  or  signals  where  a  con¬ 
tinuously  variable  status  is  conveyed  instantaneously  (e.g.,  audio 
signals,  potentiometer  controls,  thermocouple  outputs,  feedback  sig¬ 
nals,  synchro  signals,  etc.) 

d.  Video  -  signals  above  20  KHz  where  amplitude  and  time  are  used  to 
convey  information  (e.g.,  display  signals,  detected  radar  signals). 
For  the  purposes  of  this  study,  audio  signals  are  not  considered  in 
this  category  and  are  classified  as  analog  signals. 

e.  Modulated  Carriers  -  signals  where  the  information  in  any  form  is 
mixed  with  a  known  continuous  signal  for  the  purposes  of  transmis¬ 
sion  (e.g.,  IF  signals  or  RF  signals  transmitted  or  received  via  an 
antenna) . 

Binary  and  analog  signals  are  used  primarily  for  status  and  control  in¬ 
formation.  Video  and  modulated  carrier  signals  are  used  primarily  for  the 
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transfer  of  Information.  Digital  signals,  because  of  the  coded  characteris¬ 
tics,  may  be  used  for  both  purposes.  The  requirements  for  each  signal  type 
are  dictated  by  the  individual  subsystem.  The  manner  in  which  the  interfaces 
can  be  implemented  is  primarily  a  function  of  timing  relationships. 

Signals  may  be  required  continuously,  aperiodically ,  or  with  some  regu¬ 
larity  over  time.  Additionally,  the  signals  may  for  reasons  other  than  infor¬ 
mation  content  be  required  to  be  available  on  a  continuous  basis  (e.g.,  safety 
of  flight  considerations).  Signals  that  are  required  continuously,  or  to  be 
available  continuously,  and  signals  with  strict  time  dependencies  need  to  have 
dedicated  interfaces.  Dedicated  or  continuous  interfaces  for  all  signal  types 
are  required,  however,  multipurpose  interfaces,  where  applicable,  offer  signi¬ 
ficant  advantages  to  weapon  system  avionics.  The  obvious  advantages  are 
weight,  size,  and  power  reductions.  Somewhat  less  obvious  are  increases  in: 
reliability  and  maintainability  (by  reduction  in  wire  counts);  the  degree  of 
achievable  system  integration  (by  more  access  to  information);  and  the  growth 
capability  (due  to  the  flexibility  of  multipurpose  interfaces).  Multipurpose 
interfaces  fall  into  two  categories  switched  and  miltlplexed. 

Switched  interfaces  for  signals  needed  aperiodically  provide  a  reconfig- 
urable  arrangement  of  dedicated  interfaces  and  except  for  the  swtiching  re¬ 
quirements,  will  be  treated  as  dedicated  interfaces.  Multipurpose  dedicated 
interfaces  (e.g.,  a  control  line,  which  has  a  different  meaning  during  BIT) 
which  may  be  considered  a  form  of  switching  accomplished  internal  to  the  sub¬ 
system  will  be  considered  as  dedicated  interfaces. 

The  ability  to  multiplex  signals  is  dependent  on  the  multiplex  technique 
and  the  signal  type.  Any  of  the  signal  types  converted  into  a  modulated  car¬ 
rier  (by  AM,  FM,  PM,  FSK)  are  compatible  with  frequency  multiplexing.  The 
time  dependent  nature  of  binary,  analog,  video,  and  modulated  carriers  is  in 
general  incompatible  with  time  nultiplexing.  The  property  of  digital  signals 
that  information  is  transferred  over  a  fixed  period  of  time,  make  these  sig¬ 
nals  compatible  with  time  multiplexing. 
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Point-to-point  signals  that  are  multiplexed  by  a  subsystem  to  increase 
the  information  transfer  on  a  single  interface  (e.g.,  interleaved  roll  and 
pitch  attitude  information)  will  be  considered  a  single  signal.  Multiplexing 
in  the  context  of  this  report  is  a  technique  used  for  distribution  purposes. 

Each  of  the  interface  types  is  discussed  individually  in  the  following 
sections  along  with  the  distribution  media  for  the  signals,  i.e.,  dedicated, 
switched,  multiplexed.  In  the  discussion,  negative  comments  regarding  current 
practices  or  dificiencies  in  current  techniques  are  italicised.  For  each 
italicised  comment  a  positive  recommendation  is  given  in  Section  6.0. 

5.1  DEDICATED  INTERFACES 


Dedicated  interfaces  are  required  in  a  number  of  different  applications, 
e.g.,  for  signals  with  time  critical  requirements,  for  control  over  probabil¬ 
ity  of  false  alarm,  for  safety  of  flight,  and  for  signals  with  a  large  infor¬ 
mation  content  (broad  bandwidth  or  a  high  data  rate).  Dedicated  interfaces 
for  binary,  digital,  analog,  video,  and  modulated  carrier  signals  are  neces¬ 
sary  to  accommodate  general  weapon  system  avionics  requirements.  There  are 
no  military  standards  for  general  purpose  dedicated  interfaces.  DOD-STD-1399B 
recognized  the  need  for  such  standards  for  shipboard  systems,  however,  to  date 
only  requirements  for  the  use  of  standard  components  and  the  documenting  of 
electrical  interfaces  have  been  published. 

Standardization  of  dedicated  interfaces  is  necessary  in  order  to  simplify 
integration  efforts,  to  meet  new  requirements,  and  to  preclude  the  necessity 
for  adaptation  of  GFE  to  the  weapon  system  avionics  architecture. 

5.1.1  Binary  Interfaces 


Binary  interface  requirements  are  similar  to  those  of  digital  interfaces 
except  in  the  criticality  of  timing  and/or  in  their  electrical  format.  Oedi- 
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cated  binary  interfaces  that  are  not  constrained  by  electrical  format  require¬ 
ments  (i.e.,  discrete  I/O  signals)  will  be  treated  as  digital  signals  (for  ex¬ 
ample,  status/ mode/command  signals  and  timing  signals)  since  the  physical  in¬ 
terface  requirements  are  the  same.  Only  two  types  of  electrically  constrained 
binary  signals  should  be  required  in  future  avionics  subsystems.  Subsystem 
on/off  power  inputs  will  be  required  and,  in  cases  where  safety  of  flight  is 
concerned,  dedicated  status  and  warning  outputs  are  necessary. 

5. 1.1.1  Power  Input 

Subsystem  power,  even  though  controlled  by  a  power  distribution  subsys¬ 
tem,  will  require  a  subsystem  on/off  interface.  Historically  this  interface 
has  been  accomplished  by  several  methods:  switch  control  of  the  input  power 
leg,  switch  control  of  the  return  leg  (switched  ground  primarily  used  for  28  V 
dc  input),  and  switch  control  of  a  signal  (primarily  switched  28  V  dc  power  or 
ground  leg)  used  to  operate  a  subsystem  relay  for  application  of  115  V  ac. 

With  the  advent  of  sophisticated  power  distribution  subsystems  (Advanced  Avi¬ 
onics  Electrical  System  (AAES)  for  example)  only  the  equivalent  of  switch  con¬ 
trol  of  the  prime  input  power  leg  should  be  required.  Although  the  incorpora¬ 
tion  of  AAES  will  provide  switching  of  input  power  in  the  aircraft,  the  loca¬ 
tion  of  switching  used  in  the  interim  will  not  have  impact  on  AAES  incorpora¬ 
tion.  Switching  located  in  the  aircraft  would  be  replaced  by  the  new  power 
subsystem.  The  conversion  from  115  V  ac  400  Hz  to  270  V  dc  prime  power  would 
require  replacement  of  power  supplies  in  individual  equipment  and  thus  any 
switching  incorporated  in  the  power  supply  would  be  removed  via  the  replace¬ 
ment. 


In  order  to  allcw  simple  and  safe  cockpit/station  controls,  it  is  recom¬ 
mended  that  all  power  interfaces  be  required  to  operate  via  a  switched  ground 
return  to  28  V  dc  (maximum  current  0.2  ampere)  which  controls  the  input  power 
by  switching  within  the  subsystem.  This  may  necessitate  additional  hardware 
(relays)  in  each  subsystem,  however,  it  will  provide  uniform  cockpit  controls 
which  will  aid  in  the  conversion  to  an  AAES  type  subsystem.  The  additional 
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relays  can  be  removed  when  conversion  to  an  AAES  type  subsystem  is  made.  The 
necessity  for  additional  hardware  will  only  occur  in  moderate  current  28  V  dc 
subsystems.  For  safety  purposes,  subsystems  requiring  externally  switched  115 
V  ac  or  high  current  28  V  dc  are  normally  controlled  through  relays  that  are 
part  of  the  aircraft.  The  shift  in  responsibility  for  power  relays  to  the 
subsystems  is  not  overburdening,  particularly  when  safety,  reliability,  and 
commonality  are  considered.  Additionally,  this  shift  would  reduce  the  impact 
of  AAES  on  existing  platforms. 

5. 1.1.2  Warnings 

Control  and  display  of  cockpit/station  warning  lights/ tones,  etc.,  are 
readily  amenable  to  digital  multiplexed  interfaces.  However,  since  the  func¬ 
tions  for  which  these  indications  are  required  sometimes  involve  safety  or 
safety  of  flight  considerations,  it  is  not  recommended  that  all  such  warnings 
be  processed  by  multiplexing. 

It  is  recommended  that  all  safety  or  safety  of  flight  warning  outputs  be 
of  a  current  sink  type  (maximum  of  0.2  ampere  from  28  volts).  This  interface 
is  compatible  with  direct  control  of  instrument  panel  warnings  and  is  also 
compatible  with  light  dimming  circuitry.  Flashing  or  blinking  of  warnings 
should  not  be  accomplished  through  this  interface.  Warnings  requiring  flash¬ 
ing  or  blinking  should  be  output  via  a  continuous  dedicated  binary  interface 
with  the  on/off  warning  timing  controlled  in  the  instrument  panel.  This  ap¬ 
proach  prevents  annoying  asynchronous  warnings  and  allows  synchronization  with 
audio  warnings. 

5.1.2  Digital  Interfaces 

Any  type  of  electronic,  as  opposed  to  electrical,  binary  signal  requiring 
point-to-point  interface  will  be  considered  a  dedicated  digital  interface. 
Digital  information  is  in  general  a  coded  format  and  the  compatibility  of  for¬ 
mat  as  well  as  physical  signal  type  is  necessary  for  true  interoperability. 
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For  dedicated  digital  signal  interfaces,  standardization  of  format  is  con¬ 
sidered  impractical,  however,  it  is  practical  to  standardize  the  physical  par¬ 
ameters  of  the  interface.  For  discrete  I/O  signals  only  standardization  of 
physical  parameters  is  required. 

The  data  rate  requirements  for  digital  interfaces  as  considered  in  this 
report  vary  from  10“^  to  10"*"^  baud.  Discrete  I/O  signals  may  not  change  state 
for  periods  of  hours,  (e.g.,  subsystem  mode  control).  Serial  digital  data 
transfers  may  operate  at  megabit  rates  continuously.  Although  the  require¬ 
ments  for  digital  signals  may  vary  significantly,  since  the  majority  of  dedi¬ 
cated  digital  interfaces  will  be  necessary  because  of  the  criticality  of  tinr¬ 
ing  or  high  data  rate  considerations,  a  single  standard  is  considered  prudent. 

5. 1.2.1  Existing  Standards 

There  are  a  number  of  standards  and  specifications  regarding  digital  in¬ 
terfaces,  however,  with  few  exceptions  a  single  standard/specif ication  does 
not  comply  with  the  range  of  requirements  of  the  others. 

MIL-STD-188C  is  applicable  to  military  communications  systems.  For  digi¬ 
tal  signals  standards  for  low  level  (+6  V  one  wire)  and  high  level  (+60  V  one 
wire,  not  recommended)  were  established.  The  applicable  requirements  of  MIL- 
STD-188C  are  to  be  replaced  by  MIL-STD-188-100  for  common  long  haul  and  tacti¬ 
cal  communicaton8  systems  and  MIL-STD-1 88-200  for  tactical  communications  sys¬ 
tems.  MIL-STD-188-200  has  not  been  issued.  MIL-STD-188-100  describes  bal¬ 
anced  voltage  (+3  V  on  two  wires)  and  unbalanced  voltage  (+6  V  one  wire)  low 
level  interfaces  and  repeats  the  not  recommended  high  level  interface  of  MIL- 
STD-188C.  MIL-STD- 188-1 14  supersedes  the  low  level  interface  requirements  of 
both  MIL-STD- 188C  and  MIL-STD-188-100. 

FED-STD-1020  and  FED-STD-1030  adopt  EIA-RS-422  (balanced  voltage)  and 
EIA-RS-423  (unbalanced  voltage)  interfaces  respectively  in  their  entirety  for 
telecommunications  equipment.  MIL-STD-188-1 14  is  basically  a  restatement  of 
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EIA-RS-422  and  EIA-RS-423  and  hence  is  compatible  with  FED-STD-1020  and  FED- 
STD-1030  with  one  important  exception.  In  order  to  allow  for  common  mode  vol¬ 
tage  (i.e.,  induced  potential  on  both  leads)  for  the  balanced  voltage  inter¬ 
face,  the  requirements  for  EIA-RS-422  line  driver  outputs  are  not  stated  rela¬ 
tive  to  a  ground  potential.  M1L-STD-188-1 14  requires  (indirectly)  that  the 
signals  on  the  two  lines  of  the  balanced  interface  be  of  opposite  polarity 
relative  to  ground  in  order  to  maintain  compatibility  with  the  unbalnced  MIL- 
STD-188-100  and  HIL-STD-188C  receiver  interfaces  (i.e.,  each  balanced  output 
line  must  swing  above  and  below  ground  for  compatibility  with  the  older  +6V 
one  wire  receiver).  As  described  in  MIL-STD-188-1 14,  the  only  electrical  in- 
compatiblity  between  any  combination  of  balanced  or  unbalanced  receivers  or 
line  drivers  for  any  of  the  low  level  MIL-STD-188  or  federal  standards  is  that 
the  FED-STD-1020  balanced  generators  cannot  drive  a  MIL-STD-188C  or  a  MIL- 
STD-188-1 00  unbalanced  low  level  receiver.  There  is  also  a  convention  incom¬ 
patibility  with  MI L-STD- 188—100  in  that  the  meaning  of  1  and  0  is  reversed  be¬ 
tween  MIL-STD-188-100  and  MIL-STD-188-1 14.  The  rationale  for  requiring  elec¬ 
trical  compatibility  for  a  mixture  of  balanced  line  drivers  and  older  unbal¬ 
anced  line  receivers ,  when  sign  compatibility  is  not  achieved  in  any  combina¬ 
tion  between  MI L-STD- 13 8-1 00  and  MIL-STD-188-114,  does  not  make  sense,  partic¬ 
ularly  since  the  implementation  of  MIL-STD-188-114  balanced  interface  requires 
dual  voltage  power  supplies  and  the  implementation  of  FED-STD-1020  (or  EIA- 
RS-422)  does  not. 

For  other  than  teleconumni  cat  ions  equipment,  there  is  no  general  military 
standard.  Each  equipment  utilizes  its  own  interface  which  is  not  necessarily 
compatible  with  other  equipment,  (e.g.,  AN/AYK-14  Discrete  Interface  Module 
utilizes  EIA-RS-422  and  EIA-RS-423  compatible  interfaces,  whereas  the  PROTEUS 
module  utilizes  MIL-M-38510/ 104-03/04  line  drivers  and  receivers  which  should 
be  corapatable  with  EIA-RS-422  but  are  not  required  to  be,  while  each  of  the 
four  Navy  Tactical  Data  System  (NTDS)  Interface  modules  is  different  from  the 
other  and  none  is  compatible  with  EIA-RS-422).  MIL-STD-1397  describes  the 
four  NTDS  interfaces  for  use  on  ships,  however,  since  none  of  the  four  is  the 
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same  as  those  of  the  MIL-STD— 188  series  or  other  general  avionics  interfaces 
they  are  not  considered  a  basis  for  an  avionics  equipment  standard. 

None  of  the  existing  standards  adequately  address  requirements  for  other 
than  single  point-to- single  point  dedicated  digital  interfaces.  In  the  prac¬ 
tical  application  of  digital  and  binary  interfaces  fail  safe  provisions  are 
required  (i.e.  ,  proper  input  state  sensed  when  interconnecting  equipment  is 
missing  or  turned  off).  In  order  to  justify  requiring  standard  interfaces  they 
must  be  compatible  with  future  integration  as  well  as  equipment  interchangea¬ 
bility.  Even  when  standard  interfaces  are  employed,  design  practices  used  for 
fail  safe  operation  and  line  termination  may  limit  the  ability  to  further  in¬ 
tegrate  subsystems.  This  is  so  because  the  line  drivers  are  limited  by  the 
fail  safe  and  line  impedance  terminations  in  the  number  of  receivers  they  can 
drive. 


The  EIA  standards  have  been  modified.  The  latest  versions  are  RS-422A 
and  RS-423A  which  incorporate  minor  requirements  for  additional,  although  not 
complete,  compatibility  with  International  Telephone  and  Telegraph  Consulta¬ 
tive  Committee  Recommendations.  In  the  revised  EIA  standards,  the  problem  of 
multiple  receivers  and  line  terminations  is  recognized  but  not  adequately 
addressed . 


5. 1.2. 2  Future  Requirements 

The  dedicated,  point  to  point  transmission  of  digital  information  at 
rates  above  10  MHz  is  not  anticipated  in  the  future.  The  limitation  is  based 
on  the  constraints  of  signal  skewing  due  to  transmission  delays  encountered  in 
aircraft  installations.  Transmissions  at  higher  rates  are  practical  only  if 
the  clock  (sync)  information  is  sent  over  the  same  interface.  If  such  inter¬ 
faces  are  required,  the  use  of  point  to  point  optical  transmission  would  be 
the  most  practical  medium  based  solely  on  Electromagnetic  Interference  (EMI) 
considerations.  The  use  of  an  optical  transmission  medium  for  point  to  point 
transfer  of  digital  information  at  or  below  10  MHz  is  in  general  not  justified 
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since  the  same  function  can  be  performed  by  a  cheaper,  lighter  weight  electri¬ 
cal  interface.  In  specific  cases  Electromagnetic  Pulse  considerations  may 
justify  such  interfaces.  Transmission  at  higher  data  rates  over  optical 
transmission  lines  for  the  purpose  of  replacing  rmltiple  electronic  interfaces 
is  justified  and  is  discussed  in  bus  requirements. 

The  EIA-RS-422  and  EIA-RS-423  standards  can  satisfy  the  anticipated  fu¬ 
ture  needs  for  dedicated  digital  interfaces  assuming  that  no  more  than  6  to  10 
receivers  will  ever  need  to  receive  the  same  information  from  a  single  line 
driver  (see  6. 2. 1.2).  With  few  exceptions,  this  is  a  reasonable  assumption. 
The  only  difference  between  EIA-RS-422  and  EIA-RS-423  is  in  the  line  driver 
requirements  since  the  actual  line  receiver  requirements  are  identical.  The 
EIA-RS-423  line  driver  is  a  single  wire  interface  whereas  the  EIA-RS-422  line 
driver  supplies  a  differential  output  on  two  wires.  A  number  of  the  applica¬ 
tions  discussed  for  digital  interfaces  do  not  require  balanced  voltage  cir¬ 
cuits  (EIA-RS-422),  hence  use  of  the  single  wire  unbalanced  circuit  (EIA- 
RS-423)  would  allow  a  reduction  in  aircraft  wire  count  and  associated  weight, 
along  with  increased  reliability  relative  to  the  balanced  voltage  circuit 
utilization.  Despite  the  advantages  of  having  two  types  of  interfaces  for 
differing  applications,  only  the  use  of  balanced  voltage  circuits  is  recom- 
me nded. 

A  general  military  standard  adopting  EIA-RS-422  type  interfaces  for  use 
in  all  future  digital  interfaces  is  recommended.  Exclusion  of  the  single  wire 
interface  is  recommended  for  two  reasons.  The  interface  connector  pin  limita¬ 
tions  on  modern  avionic  equipment  will  force  increased  use  of  other  than  dedi¬ 
cated  digital  interfaces  where  they  are  not  necessary  if  the  balanced  inter¬ 
face  is  required.  Secondly,  the  number  of  applications  where  a  dedicated  dig¬ 
ital  interface  is  required  and  the  unbalanced  interface  is  adequate  are  not 
significant  enough  to  warrant  a  separate  interface  standard.  This  is  particu¬ 
larly  true  when  EMI  and  the  common  mode  rejection  capabilities  of  the  balanced 
interface  are  considered. 
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In  order  to  all<xv  for  future  Integration  (as  well  as  the  bus  interfaces 
discussed  in  5. 3. 1.3),  dedicated  digital  interfaces  should  be  configured  so 
they  are  multipurpose.  For  tailt ipurpose  application,  tri-state  operation  of 
line  drivers  is  required.  The  use  of  the  tri-state  line  drivers  is  only  ef¬ 
fective  when  the  subsystem  containing  the  line  driver  is  externally  controlled 
(i.e.  ,  line  driver  output  is  generated  in  response  to  an  external  input  which 
causes  the  tri-state  output  to  transition  from  the  high  impedance  to  digital 
output  mode).  For  dedicated  interfaces,  this  type  of  operation  is  unusual 
since  it  is  simpler  to  let  the  dedicated  line  driver  free  run  and  have  the  ex¬ 
ternal  control  signal  manipulate  the  sampling  of  the  information  at  the  line 
receiver.  Discontinuing  this  practice  and  requiring  the  use  of  tri-state  line 
drivers  wherever  possible  has  the  potential  of  allowing  dedicated  interfaces 
to  act  as  busses  in  future  integration  efforts. 

5.1.3  Analog  Interfaces 

Analog  or  proportional  interfaces  are  being  replaced  by  digital  inter¬ 
faces  at  a  rapid  rate;  however,  analog  interfaces  are  not  likely  to  become 
completely  obsolete  in  the  near  future.  The  conversion  of  a  signal  to  digital 
format  is  limited  by  sampling  rate  requirements.  There  are  also  accuracy  lim¬ 
itations  to  a  digital  conversion,  but  for  signals  propagated  through  aircraft 
wiring  the  quantization  error  of  a  digital  conversion  may  be  less  than  the  in¬ 
duced  EMI  errors.  Devices  that  are  compatible  with  digitization  will  require 
analog  interfaces  until  the  signal  reaches  the  point  where  the  conversion 
takes  place  (e.g.,  voice,  potentiometer  settings,  synchros,  temperature  sen¬ 
sors,  etc.).  Complete  elimination  of  analog  interfaces  would  require  addi¬ 
tional  hardware  (power  supplies,  Analog  to  Digital  (A/D)  converters)  located 
with  remote  devices. 

There  is  no  strong  technical  reason  for  standardizing  analog  interfaces 
since  they  are  dedicated  special  purpose  interfaces.  The  integration  of  fu¬ 
ture  systems  could  benefit  from  standardized  interfaces  particularly  where  fu¬ 
ture  technology  has  the  potential  of  revising  the  sampling  rate  limitations  of 
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digital  conversions.  For  this  reason,  along  with  the  fact  that  reasonable 
standards  should  not  have  a  measurable  impact  on  future  subsystems,  standardi¬ 
zation  for  amplitude  analog  and  phase  analog  signals  is  recommended. 

Two  standards  for  amplitude  analog  signals  are  recommended  to  accommodate 
unipolar  (0-10  V  dc  recommended)  and  bipolar  (-5  to  +5  V  dc  recommended)  sig¬ 
nals.  The  recommended  signal  ranges  are  arbitrary.  However,  equivalent  peak 
to  peak  swings  for  bipolar  and  unipolar  signals  are  strongly  recommended  in 
order  to  allow  common  voltage  quantization  values  for  the  two  types  of  inter¬ 
faces. 

Two  standards  for  phase  analog  signals  are  recommended  to  allow  synchro 
to  digital  conversions  of  back-up  flight  control  displays  in  future  avionics 
integration.  The  recommended  ranges  are  those  currently  utilized,  namely  26  V 
and  115  V  levels. 

5.1.4  Video  Interfaces 


Video  signals  are  utilized  primarily  for  detected  radar  or  sync  and  video 
display  information  where  signal  amplitude  and  timing  convey  the  Information. 
Approximately  16.9  MHz  bandwidth  is  required  for  display  information.  Radar 
return  information  requirements  are  a  function  of  radar  parameters.  Standard¬ 
ization  of  both  these  interfaces  can  have  significant  impact  in  future  avion¬ 
ics. 


Subsystems  requiring  cockpit/station  display  are  often  procured  separ¬ 
ately  from  the  display,  thus  standardization  would  offer  a  means  of  mixing  and 
matching  displays  and  subsystems  as  well  as  allowing  increased  utilization  of 
station  displays  for  different  missions.  Radar  video  signals  are  typically 
very  special  purpose  in  nature;  however,  electronic  warfare  and  radar  altim¬ 
eter  video  information  have  potential  application  for  use  by  other  subsystems. 
Standardization  for  radar  video  signals  (17  MHz  bandwidth  for  a  120  nsec 
pulse)  would  facilitate  future  utilization  of  this  information. 
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Although  there  Is  no  reason  to  use  the  same  standards  for  radar  video  and 
display  sync  and  video,  the  requirements  are  so  similar  that  there  Is  no  rea¬ 
son  not  to  use  the  same  standard  and  thus  reduce  the  number  of  different  stan¬ 
dards.  A  standard  17  MHz  Interface  for  both  type  signals  is  recommended. 
However,  care  should  be  taken  to  have  this  standard  applicable  only  to  signals 
where  both  time  and  amplitude  convey  information.  Signals  that  are  often 
treated  as  video  (e.g.,  blanking  signals  or  transmitter  pul3e  modulation  sig¬ 
nals)  do  not  require  amplitude  information  and  should  be  treated  as  binary 
signals. 

5.1.5  Modulated  Carriers 


The  requirements  for  modulated  carrier  signals  include  carrier  frequen- 

*3  1  Q 

cies  in  the  range  of  10  to  10  Hz  and  higher  if  optical  transmissions  are 
considered  in  this  category.  Interfaces  for  these  signals  are  usually  very 
subsystem  sensitive  (e.g.,  RF  transmissions  by  the  subsystem  or  specialized 
IF  signals).  General  standardization  for  modulated  carriers  is  not  possible 
without  subsystem  performance  impact  and  is  not  considered  prudent. 

It  is  possible  to  generate  a  skeletal  standard  that  describes  only  broad 
requirements  for  optical  interfaces,  however,  at  this  point  in  the  technology, 
such  a  standard  is  considered  premature.  A  preliminary  standard  describing 
general  requirements  of  optical  fiber  connectors  has  been  drafted  (MIL-C- 
85044)  and  a  general  requirements  standard  for  fiber  optic  cables  is  in  effect 
(D0D-C-85045) .  General  standards  for  optical  interfaces  should  be  delayed  un¬ 
til  broader  application  of  the  technology  is  achieved. 

The  first  IF  frequency  utilized  in  most  radio  coranunications  equipment  is 
typically  70  MHz.  Because  of  the  proliferation  of  radio  receivers  and  trans¬ 
mitters  on  a  single  weapon  system  (e.g.,  2  UHF  transceivers  each  with  a  sepa¬ 
rate  guard  channel,  auxiliary  UHF  receiver  with  a  guard  channel,  and  a  UHF 
digital  data  transceiver)  standardization  of  the  first  IF  frequency  could  have 
significant  commonality  and  reliability  impact.  If  access  to  the  first  IF 
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were  available  ( recommended  action  to  achieve  capability  in  6. 1.2. 3. 2),  the 
transmitter  and  receiver  assets  could  be  reconfigured  by  IF  switching  (recom¬ 
mended  development  in  6. 4. 2. 3)  to  perform  the  required  functions,  thus  achiev¬ 
ing  greater  functional  commonality  as  well  as  increased  reliability.  For  this 
reason,  a  standardized  IF  interface  for  radio  comminlcations  equipment  is  rec¬ 
ommended. 

5 . 2  SWITCHED  INTERFACES 


As  noted  earlier  switched  interfaces  are  used  primarily  to  provide  a  re- 
configurable  arrangement  of  point  to  point  dedicated  interfaces.  The  switch¬ 
ing  of  interfaces  is  required  for:  control  of  standby  redundant  assets;  con¬ 
figuration  or  mode  change  (e.g.,  ADF  vs.  omnidirectional  processing  or  secure/ 
clear  voice);  management  of  scarce  resources  (e.g.,  antenna  switching  ). 

The  advisability  of  utilizing  switching  to  control  redundant  standby  as¬ 
sets  is  highly  dependent  on  the  number  of  failure  paths  and  the  reliability  of 
the  elements,  the  switching  device,  and  failure  monitors.  Since  the  method  of 
switching  implemented  affects  the  reliability  of  the  subsystem  and  the  reason 
for  implementing  switching  is  to  improve  reliability,  it  is  not  considered 
prudent  to  place  general  requirements  on  redundancy  switching. 

Switching  to  accomplish  configuration  or  mode  changes  may  involve  any  of 
the  signal  types  discussed  above.  Multiplexing  used  in  lieu  of  switching  is 
attractive  particularly  since  frequency  multiplexing  is  conqpatable  with  all 
signal  types.  The  implementation  of  frequency  multiplexing  requires  a  signi¬ 
ficant  hardware  investment  which  is  not  justified  for  simple  switching  re¬ 
quirements.  In  those  cases  where  multiplexing  is  not  cost  effective,  continu¬ 
ation  of  current  practices  utilizing  relay  control  matched  to  a  weapon  system 
requirements  is  considered  adaquate.  Relay  control  should  be  standardized 
using  the  binary  interface  type  discussed  in  5.1.1.  Since  it  is  assumed  that 
the  signals  to  be  switched  are  standardized,  the  lack  of  standardization  in 
switching  implementation  should  have  no  impact  on  future  integration.  This  is 
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true  since  switching  involves  only  the  destination  of  the  signal  and  integra¬ 
tion  efforts  can  utilize  the  signal  source  without  being  affected  by  the 
switching. 

Another  reason  for  allowing  weapon  system  independant  switching  is  for 
comparability  with  Red/Black  requirements.  Although  not  completely  resolved, 
a  strict  interpretation  of  Red/Black  requirements  would  require  every  element 
on  a  multiplexed  bus  (time  or  frequency)  that  contained  classified  information 
to  meet  Red  requirements.  By  allowing  for  independant  switching  only  the  ele¬ 
ments  actually  requiring  classified  information  or  the  switches  and  controls 
would  need  to  meet  Red  requirements. 

An  alternative  to  both  discrete  switching  and  multiplexing  is  multiplex 
switching.  This  alternative  is  attractive  where  frequency  multiplexing  is  not 
cost  effective  or  where  discrete  switching  is  overly  complex,  e.g.,  reconfigu¬ 
ration  of  three  or  more  elements.  One  application  for  multiplex  switching  is 
for  the  IF's  of  radios. 

A  higher  degree  of  functional  commonality  for  radios  could  be  achieved  by 
control  of  the  IF  signals.  Guard  channels  are  provided  in  auxiliary  radios 
(receive  only)  as  well  as  general  radios.  Seperate  UHF  transmitters  are  util¬ 
ized  for  digital  data  and  voice  often  when  a  redundant  voice  radio  is  incorpo¬ 
rated  in  the  weapon  system.  Having  the  capability  to  reconfigure  radio  assets 
via  switching  of  the  IF  would  allow  greater  utilization  of  assets.  It  would 
also  simplify  switching  between  radio  types  (e.g.,  UHF  to  VHF)  and  in  the  pro¬ 
cessing  of  ADF  functions.  For  this  reason  development  of  a  stand-alone,  fail¬ 
safe,  solid  state,  four  by  four,  70  MHz  multiplex  switching  network  is  recom¬ 
mended.  The  any  one  of  four  input  to  any  one  of  four  output  arrangement  is 
recommended  since  it  Is  the  simplest  arrangement  that  will  allow  multiplatform 
application.  The  70  MHz  IF  is  recommended  since  it  is  compatible  with  many 
existing  first  IF's.  In  order  for  this  development  to  be  maximally  effective , 
the  sijnal  requirements  for  all  radios  must  be  standardized  or  the  radios  must 
be  made  multipurpose.  The  multiplexed  IF  switching  achievable  with  such  a  unit 
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would  allow  simultaneous  and  reconf igurable  operation  of  resources  to  perform 
such  functions  as  voice  comnunlcatlon,  ADF ,  guard  monitoring  and  data  link. 

Switching  is  required  for  the  utilization  of  scarce  resources.  The  major 
application  of  this  type  switching  is  for  RF  signals  to  antennas.  In  this 
area  there  is  no  necessity  for  all  switching  to  be  weapon  system  dependent,  at 
least  for  UHF,  TACAN,  IFF  and  ADF  antennas,  since  the  requirements  are  common 
across  weapon  systems.  For  this  reason  development  of  a  standard  antenna 
switching  unit  is  recommended. 

5.3  MULTIPLEXED  INTERFACES 


Both  time  and  frequency  multiplexing  of  signals  used  in  avionics  equip¬ 
ment  are  practical.  However,  because  of  timing  constraints  on  other  types  of 
signals,  only  digitally  formatted  information  will  be  considered  for  time  mul- 
t iplexing. 

5.3.1  Time  Multiplexing 

The  requirement  for  distribution  of  specific  digital  information  in  a 
given  format  is  typically  only  from  point  to  point.  Despite  this  fact,  a  com¬ 
mon  method  of  distribution  is  by  bus,  i.e.  ,  a  common  lead(s)  with  multiple 
connections  that  can  serve  as  a  point  to  point  interconnection  for  many  ele¬ 
ments  and,  if  required,  a  point  to  several  points  interconnection.  There  have 
been  two  major  reasons  for  the  application  of  busses  to  provide  what  is  es¬ 
sentially  point  to  point  communications,  namely,  as  a  means  of  reducing  inter¬ 
faces  and  hardware  and  the  fact  that  available  point  co  point  links  are  cap¬ 
able  of  transferring  information  faster  than  the  recipient  can  use  it.  The 
reduction  in  hardware  and  interfaces  is  achieved  by  using  one  interface  in 
each  unit  to  provide  all  similar  point  to  point  interfaces  for  that  unit.  The 
one  interface  rationale,  when  applied  to  several  units  with  different  point  to 
point  coranunications  requirements  among  themselves,  will  logically  lead  to  a 
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bus  configuration.  The  bus  is  feasible  only  because  it  can  carry  more  infor¬ 
mation  than  the  sum  of  all  the  users  need  to  receive. 

Although  not  a  major  technical  reason  for  utilizing  a  bus,  the  flexibil¬ 
ity  in  terms  of  the  addition  or  change  of  elements  in  an  avionics  architecture 
that  is  achieved  almost  without  cost  by  a  bus  configuration  has  led  to  general 
acceptance  of  this  medium.  The  wide  acceptance  of  this  medium  should  not 
overwhelm  its  technical  application,  particularly  when  future  technology 
trends  are  considered.  With  the  ever-increasing  speed  of  digital  processors 
and  the  expected  impulse  to  this  increasing  trend  that  will  be  provided  by  de¬ 
velopments  such  as  very  high  speed  integrated  circuits  (VHS1C),  the  technical 
feasibility  of  continued  bus  techniques  should  be  examined  relative  to  the 
flexibility  advantages. 

A  bus  is  technically  justified  for  a  given  application  only  if  it  reduces 
hardware  requirements  and  has  enough  excess  capacity  to  insure  that  multiplex¬ 
ing  does  not  affect  the  ability  of  the  recipient  to  perform  the  required  func¬ 
tions.  As  the  application  of  digital  processing  becomes  more  widespread  and 
the  ability  of  processing  elements  to  assimilate  and  exchange  more  information 
increases,  the  requirements  for  bus  data  rates  will  also  increase.  The  com¬ 
bined  effect  of  more  units  interfacing  to  the  bus  and  the  desirability  of  a 
larger  information  exchange  will  cause  the  bus  data  rates  requirements  to  in¬ 
crease  dramatically.  Only  if  the  emerging  technology  in  the  area  of  busses 
can  achieve  the  required  data  rates,  and  actually  utilize  fewer  resources 
(hardware  and  software)  than  point  to  point  counterparts,  can  the  flexibility 
advantage  of  bus  techniques  be  considered  cost  free. 

5, 3. 1.1  Digital  Information  Types 

Information  in  digital  format  that  is  used  by  the  weapon  system  avionics 
has  many  different  characteristics,  it  may  vary  from  individual  bits  repre¬ 
senting  the  state  of  discrete  switch  positions  to  conqplex  groupings  of  bits 
representing  encoded  information.  For  the  purpose  of  this  discussion,  all 
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digital  information  is  assumed  to  be  in  groups  of  bits  (words)  which  may  con¬ 
tain:  multiple  pieces  of  information  (binary  representation  of  many  indivi¬ 

dual  switch  positions),  a  single  piece  of  information  (binary  representation 
of  a  value  or  instruction),  or  less  than  a  single  piece  of  information  (encod¬ 
ed  video  binary  string  or  partial  instructions).  The  types  of  digital  infor¬ 
mation  that  need  to  be  considered  for  avionics  subsystems  are: 

a.  Control  Word  -  digital  words  that  require  one  or  more  actions  to  be 

taken  by  the  recipient. 

b.  Data  Word  -  a  digital  word  that  contains  information  relevant  to 

the  operation  of  the  recipient. 

c.  String  -  a  group  of  digital  words  which  contain  information 

relevant  to  the  operation  of  the  recipient  but  for 
which  individual  words  contain  no  useful  information. 

d.  Block  -  a  group  of  digital  words  where  each  word  contains 

useful  information  but  the  entire  group  of  words  is 
required  in  order  to  be  relevant  to  the  operation  of 
the  recipient. 

The  terms  above  have  precise  meanings  in  many  other  contexts  that  differ 
from  the  definitions  above.  The  intent  of  the  above  definitions  is  to  define 
the  meanings  of  these  terms  in  the  context  of  this  discussion  and  not  to  pro¬ 
vide  universally  accepted  definitions. 

5. 3. 1.2  Existing  Standard 

MIL-STD-1 553  established  requirements  for  digital,  command/response,  time 
division  miltiplexing  (data  bus)  techniques  on  aircraft.  The  requirements  are 
for  an  alternating  differential  type  transmission  medium  operating  at  one  meg¬ 
abit  rate.  Manchester  coding  of  the  bits  Is  utilized,  hence  the  bus  actually 
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operates  at  a  2  MHz  rate,  i.e.  ,  a  50%  overhead  to  allow  error  detection  of  bit 
transmissions.  All  transmissions  on  the  bus  are  20  bit  time  words  of  which 
only  16  bit  times  contain  information.  The  additional  bit  times  are  used  for 
timing  synchronization  and  word  parity.  Because  of  the  limited  number  of 
words  in  a  transmission,  no  check  sum  type  error  detection  is  required  by  the 
standard  but  its  use  is  not  precluded  in  data  transmissions. 

The  bus  utilizes  a  single  (although  transferable)  bus  control  scheme 
where  all  other  elements  attached  to  the  bus  are  considered  remote  terminals. 
All  comnunications  are  controlled  by  the  designated  bus  control  element 
through  the  transmission  of  Command  Words  and  the  reception  of  Status  Words 
from  the  element  receiving  the  command,  (Status  Words  are  not  used  in  broad¬ 
cast  mode  -  i.e.,  transmission  of  commands  to  all  bus  elements).  The  32  bits 
of  information  contained  in  the  Command  Word  plus  Status  Word  are  allocated 
approximately  as  follows:  4  bits  reserved  for  future  growth  or  test,  3  bits 
for  fault  detection  and  management,  20  bits  for  bus  management  functions,  and 
5  bits  (Subaddress/Mode  field)  left  to  the  discretion  of  the  individual  system 
designer.  Of  the  5  bits  to  be  utilized  by  the  system  designer,  2  of  the  32 
combinations  are  reserved  to  control  the  meaning  of  5  of  the  bus  management 
bits  (i.e.,  gain  additional  control).  When  the  additional  control  (Mode)  is 
utilized,  the  additional  5  bits  of  control  (32  states  in  the  Data  Word  Count/ 
Mode  Code  field)  are  used  as  follows:  17  states  reserved  for  future  growth,  9 
states  for  fault  detection  and  management,  and  6  states  for  bus  management 
f  unctions. 

The  requirements  for  the  1553  data  bus  were  very  carefully  designed 
around  error  detection  as  is  indicated  by  the  approximately  27%  of  all  bit 
times  in  a  Coramand/Status  response  allocated  to  fault  detection  and  fault  man¬ 
agement  functions.  By  the  use  of  two  of  the  32  states  reserved  for  individual 
system  designers  remote  terminal  controls  for  redundant  busses  are  provided 
thus  increasing  the  provisions  for  fault  management. 
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Of  the  20  out  of  32  bits  (Command  Word  plus  Status  Word)  used  for  bus 
management  functions,  10  are  used  for  terminal  addressing  (5  in  the  Command 
Word  and  5  in  the  Status  Word).  The  5  bits  of  terminal  address  in  the  Status 
Word  are  redundant  in  that  their  only  purpose  is  to  insure  that  the  Status 
Word  originated  from  the  remote  terminal  to  which  the  Command  Word  was  sent. 
(In  normal  operation,  this  will  always  be  the  case.)  The  5  bits  of  address  in 
the  Command  Word  allow  control  of  30  remote  terminals  by  the  bus  controller 
since  one  address  is  assigned  to  the  bus  controller  and  one  is  reserved  for 
the  broadcast  mode.  The  provision  for  30  remote  terminals  is  sufficient  to 
accommodate  almost  any  realistic  arrangement  for  an  avionics  system.  How¬ 
ever the  limitation  of  31  total  addresses  severely  limits  the  ability  to 
utilize  the  same  elements  between  aircraft  or  systems  since  the  assignment  of 
addresses  must  be  consistent  between  aircraft  or  systems  unless  some  method  of 
reassignment  is  provided. 

The  apparent  lack  of  flexibility  provided  for  system  design  (30  states) 
is  overcome  by  the  use  of  Data  Words  which  may,  in  turn,  be  used  as  Control 
Words  for  individual  elements  on  the  bus.  The  transfer  of  data  words  in  a 
string  or  block  is  limited  to  a  maximum  of  32  words  per  transfer. 

The  1553  standard  places  no  requirements  on  how  the  bus  will  be  utilized 
other  than  the  requirement  for  compliance  with  the  specified  parameters  (broad 
description  of  electrical  interface  and  low  level  protocol).  The  four  avion¬ 
ics  examples  given  in  Section  6  of  reference  c  (F-16,  LAMPS  MK-III,  YAH-64, 
and  B-52)  all  utilize  a  fixed  remote  terminal  scheduling  technique  where  mul¬ 
tiples  of  the  basic  rate  may  also  be  used  for  timing.  This  utilization  makes 
sense  when  consideration  is  given  the  fact  that  the  bus  control  elements  will 
typically  be  part  of  a  processor  that  has  its  own  function  to  perform  and  only 
a  limited  amount  of  overhead  processing  can  be  accommodated.  The  1553  was  de¬ 
signed  to  allcw  maximum  processing  of  low  level  bus  protocol  functions  in  the 
bus  interface  without  overburdening  the  processor  to  which  it  is  interfaced. 
Higher  level  protocol  processing  (e.g.,  for  processor  to  processor  interfaces) 
is  not  addressed. 
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An  idealized  scheduled  system  would  operate  as  follows.  Assume  a  base 
sampling  rate  of  6.25  Hz  and  three  rajltiples  thereof  (example:  160,  80,  40 
and  20  msec  cycle  times)  and  provision  for  30  remote  terminals.  On  a  long 
terra  basis,  depending  on  the  base  rate,  each  terminal  would  be  allowed  a  maxi¬ 
mum  of  5333,  2666,  1333,  or  666  usee  of  bus  utilization  per  cycle.  Cycle 
times  may  be  different  for  each  remote  terminal  thus  allowing  increased  bus 
utilization  for  some  terminals,  however,  for  simplicity,  it  will  be  assumed 
that  all  terminals  are  allocated  identical  bus  utilization  rates.  The  simp¬ 
lest  information  exchange  involves  one  Command  Word  and  one  Status  Word  which 

requires  between  44  and  60  usee  to  accomplish  depending  on  response  times.  In 

this  period  (52  usee  average),  only  5  bits  of  information  are  actually  trans¬ 
ferred  thus  the  information  rate  is  10.4  usee  per  bit  average  or  96  kilobits 
per  second  (10%  of  the  actual  bit  rate).  Although  the  overhead  appears  signi¬ 
ficant,  the  actual  rates  that  are  achieved  are  considered  more  than  adequate 
for  status  and  control  functions.  When  data  words  are  utilized  to  effect  in¬ 
formation  transfer  between  remote  terminals  (RT)  and  the  bus  controller  (BC), 
the  overhead  decreases  significantly.  For  example,  a  32  word  transfer  between 
the  bus  controller  and  a  remote  terminal  requires  between  684  and  700  p sec 
(average  692  usee)  with  512  bits  of  information  transferred  resulting  in  a  740 
kilobit/sec  rate  (or  74%  of  the  actual  bit  rate).  It  should  be  noted,  how¬ 
ever,  that  this  transfer  cannot  be  accomplished  in  the  666  usee  (50  Hz  rate) 
cycle.  In  order  to  accomplish  this  transfer  in  the  minimum  cycle  time,  a  base 

rate  less  than  6  Hz  (with  a  fourth  harmonic  of  less  than  47.6  Hz)  would  be  re¬ 

quired. 

When  asynchronous  transfers  between  remote  terminals  are  necessary,  a 
significant  amount  of  overhead  is  required  to  notify  the  bus  controller  of  the 
transfer,  setup  and  effect  the  transfer,  and  check  for  completion  of  the 
transfer.  In  order  to  accomplish  this  transfer,  six  transactions  involving 
both  overhead  (7  Command  Words,  7  Status  Words,  and  4  Data  Words)  and  the  ac¬ 
tual  data  transfer  have  been  assuned.  This  overhead  requires  between  386  and 
49 J  ..  uec  depending  on  response  times.  The  transfer  of  32  words  requires  a 
total  of  1026  to  1130  psec  (average  1078  usee). 
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As  noted  earlier,  the  maximum  word  transfer  per  transaction  is  32  words. 
If  more  than  32  words  require  transfer,  several  transactions  are  required. 
Accommodating  asynchronous  transfer  between  remote  terminals  within  a  fixed 
schedule  mode  of  operation  would  in  a  single  cycle  allow:  no  32  word  transac¬ 
tion  at  the  50  Hz  (666  usec/terrainal)  sampling  rate;  one  at  the  25  Hz  (1333 
a  sec/ terminal)  sampling  rate;  two  at  the  12-1/2  Hz  (2666  u sec/terminal)  sam¬ 
pling  rate;  and  four  at  the  6-1/4  Hz  (5333  p sec/terminal)  sampling  rate.  Ex¬ 
cept  for  the  case  of  the  50  Hz  polling  rate,  the  remote  terminal  to  remote 
terminal  transfer  data  rate  would  be  800  16  bit  words/sec  maximum.  This 
transfer  rate  is  considered  acceptable  except  when  the  data  transferred  is  a 
String  or  a  Block  of  information.  As  defined  earlier,  the  recipient  of  String 
or  Block  information  cannot  complete  utilization  of  the  information  until  the 
entire  transfer  is  complete.  Thus  moderate  block  sizes  (1024  words)  would  re¬ 
quire  more  than  1  sec  to  transfer  and  would  necessitate  a  corresponding  delay 
in  processing. 

There  are  a  number  of  methods  to  get  around  this  problem,  for  example, 
reducing  the  number  of  terminals  to  be  serviced  thus  increasing  the  sampling 
cycle  time  for  each  serviced  terminal,  using  variable  cycle  times  for  differ¬ 
ent  terminals,  or  using  an  auxiliary  1553  bus  dedicated  and  interfaced  to  only 
the  terminals  requiring  asynchrous  transfers.  All  of  these  approaches  can 
perform  adaquately.  However,  if  they  are  implemented  the  flexability  in  terms 
of  growth  potential  is  not  achieved  since  the  bus  implementation  is  tuned  to 
its  initial  design.  In  the  case  of  the  auxiliary  bus  the  reduction  in  hard¬ 
ware  that  justifies  a  bus  technique  is  not  realized  since  the  auxiliary  bus  is 
really  a  dedicated  point-to-point  transfer  medium. 

In  summary,  the  1553  bus  is  considered  adequate  for  current  and  projected 
needs  for  use  as  a  status  and  control  distribution  medium  where  a  high  degree 
of  fault  detection  capability  and/or  redundant  distribution  is  required.  The 

1553  bus  is  considered  inadequate  uhere  as'jnchronous  data  transfers  between 
avionics  elements  are  required  'jhen  the  actual  utilization  practices  are  con¬ 
sidered. 


-  - 
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5.3. 1.3  Future  Requirements 

As  discussed  in  the  previous  paragraphs,  the  MIL-STD-1553  time  multiplex 
bus  is  not  considered  adaquate  for  data  transfers  between  elements  particu¬ 
larly  for  asynchronous  transfers.  In  order  to  correct  this  deficiency  in  a 
manner  compatable  with  protecting  the  Navy's  investment  in  hardware,  as  well 
as  the  commonality  already  achieved  by  the  MIL-STD-1553  bus,  the  development 
of  an  augmented  bus  to  supplement  the  data  transfer  capability  of  the  1553  bus 
is  recommended.  The  augmented  bus  recommended  (see  6. 4. 1.1)  would  operate  in 
parallel  with  the  MIL-STD-1553  bus  and  all  data  transfers  on  the  augmented  bus 
would  be  controlled  by  the  1553  bus.  The  augmented  bus  implementation  is  rec¬ 
ommended  only  for  new  elements  (remote  terminals)  in  previously  equipped  MIL- 
STD-1553  platforms  which  require  moderate  to  large  data  transfers.  The  aug¬ 
mented  bus  will  require  additional  hardware,  hcwever,  since  no  protocol  or 
control  is  involved  the  hardware  impact  would  be  significantly  less  than  the 
implementation  of  an  auxiliary  MIL-STD-1553  bus  to  perform  the  same  function. 
The  augmented  bus  should  be  considered  an  interim  measure,  (i.e. ,  a  simple 
augmenting  data  transfer  medium) . 

In  order  to  .allow  for  more  complex  digital  processing  in  future  weapon 
systems,  developments  seperate  from  the  MIL-STD-1553  are  also  recommended. 
Currently  a  nonairborne  optical  fiber  bus  development  is  underway  as  part  of 
the  Marine  Corps  Tactical  Air  Operations  Central-1985  program.  There  are 
technology  investigations  underway  for  MIL-STD-1553  optical  busses  as  well  as 
for  higher  speed  electrical  busses  as  part  of  the  SAE-A2K  committee  efforts. 
For  this  reason,  the  requirements  for  a  complete  replacement  of  the  MIL- 
STD-1553  bus  were  not  addressed  as  part  of  this  study.  It  is  recommended  that 
these  developments  continue  but  with  some  modification.  The  implementation  of 
optical  busses  is  not  dependent  on  protocol  hence  optical  bus  developments 
should  be  dedicated  to  the  development  of  optical  bus  couplers  and  interfaces 
Independent  of  protocol.  Additionally,  the  use  of  optical  busses  to  provide 
simultaneous  frequency  and  time  nultlplex  capability  (i.e.,  more  than  one  time 
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multiplex  bus  operating  simultaneously  on  one  cable)  should  be  investigated. 
The  purposes  of  higher  speed  electrical  txisses  are  to  increase  bus  efficiency 
and  flexability  through  protocol.  The  electrical  bus  developments  should  be 
dedicated  to  the  development  of  protocol  independent  of  the  transmission  medi¬ 
um.  Program  schedules  should  be  coordinated  so  that  each  will  benefit  from 
the  other.  Additionally,  parallel  studies,  as  opposed  to  developments,  should 
be  conducted  to  determine  if  VHSIC  technology  will  have  impact  on  time  multi¬ 
plex  bus  capabilities  should  the  optical  bus  hardware  developments  be  unsuc¬ 
cessful  . 

The  continuation  of  development  efforts  to  provide  a  high  speed  replace¬ 
ment  for  the  MIL-STD-l 553  serial  bus  is  recommended  even  though  the  parallel 
augmentation  bus  will  satisfy  the  near  terra  core  avionics  requirements.  This 
recommendation  is  made  primarily  because  the  number  of  units  that  can  be  at¬ 
tached  to  the  electrical  parallel  augmentation  bus  recommended  in  6. 4. 1.1  will 
be  limited  (6-10  units)  by  the  line  drivers  recomended  in  6. 2. 1.2. 2.  The  con¬ 
figuration  shown  in  Figures  l  and  2  assumes  7  augmented  bus  connections  (not 
including  mission  avionics).  The  configurtion  shown  in  Figure  3  assumes  10 
augmented  bus  connections  without  considering  mission  avionics.  When  mission 
avionics  and  core  avionics  growth  potential  are  considered,  the  recommended 
augmentation  bus  must  be  considered  an  interim  solution  for  asynchronous  data 
transfers  if  limited  to  the  interface  of  a  maximum  of  10  units.  An  alterna¬ 
tive  to  the  recommended  electrical  Interface  is  the  use  of  a  fiber  optic  link 
to  provide  augmentation  of  the  MIL-STD-1553  bus.  The  fiber  optic  link  would 
require  only  a  single  cable  since  serial  rather  than  parallel  bit  transfers 
can  be  accommodated  within  the  bandwidth  of  an  optical  bus.  The  implementa¬ 
tion  of  an  optical  augmentation  bus  could  satisfy  future  digital  data  transfer 
requirements  without  replacing  the  existing  MIL-STD-1553  bus,  however,  a  bus 
concept  that  includes  the  features  of  the  augmented  bus  (higher  speed  as  well 
as  variable  rate  data  transfers)  and  that  also  addresses  the  higher  level  pro¬ 
tocol  requirements  for  processor  to  processor  interactions  is  the  preferred 
approach. 
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5.3.2  Frequency  Multiplexing 

The  use  of  frequency  multiplexing  techniques  to  distribute  information 
over  coaxial  cables  can  offer  many  of  the  same  advantages  as  time  multiplex¬ 
ing,  namely,  point  to  point  (or  point  to  several  points)  reconf igurable  inter¬ 
faces  that  provide  flexibility  in  terras  of  changes  or  additions.  Frequency 
multiplexing  offers  an  advantage  over  time  multiplexing  in  that  is  is  compa¬ 
tible  with  all  signal  types  and  simultaneously  provides  continuous  outputs  to 
all  elements.  The  use  of  frequency  multiplexed  signals  over  coaxial  cables  is 
widespread  in  cable  television  systems,  however,  there  are  a  number  of  con¬ 
straints  which  affect  the  utilization  of  frequency  multiplexing  for  transmis¬ 
sion  of  signals  in  aircraft. 

5.3.2. 1  Bus  Configurations 

An  ideal  frequency  multiplex  bus  for  avionics  equipment  would  allow  di¬ 
rect  exchange  of  information  between  any  of  the  elements  on  the  bus  regardless 
of  position  on  the  bus.  Frequency  multiplex  systems  operate  over  a  broad 
bandwidth  in  order  to  accommodate  multiple  channels  with  reasonable  informa¬ 
tion  content  and  it  is  the  broadband  operation  that  in  general  requires  a  di¬ 
rectional  bus.  This  is  true  for  two  reasons: 

a.  In  order  to  maintain  broadband  transmission  characteristics  direc¬ 
tional  ccxiplers  are  used  to  inject  into,  and  extract  signals  from, 
the  bus,  and 

b.  to  overcome  the  losses  due  to  the  couplers  and  the  lossy  transmis¬ 
sion  line,  amplifiers  which  are  non  reciprocal  devices  are  uti¬ 
lized. 

Directional  bus  operation  can  provide  significant  flexibility  in  terms  of 
reconfiguration  of  interfaces  but  the  overall  capability  is  limited  by  the  po¬ 
sition  of  the  directional  couplers  on  the  bus  (see  Figure  4a).  For  example,  a 
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transmitter  can  send  information  to  any  number  of  receivers  downstream  but  a 
receiver  upstream  from  the  transmitter  (or  a  receiver  downstream  of  the  trans¬ 
mitter  configured  to  receive  signals  from  other  transmitters  further  down¬ 
stream)  cannot  receive  the  signal.  Thus  the  ability  to  exchange  information 
is  limited  by  the  initial  configuration  of  the  bus.  The  use  of  in  line  ampli¬ 
fiers  in  the  position  dependent  configuration  is  limited  and  once  incorporated 
further  reduces  bus  flexibility.  Commercial  systems  (See  Figure  4b)  overcome 
the  configuration  limitations  by  having  all  the  transmitters  send  signals  up¬ 
stream  to  the  "head  end"  where  they  are  converted  to  a  different  channel  and 
re-transmitted  downstream  for  receipt  by  downstream  receive  couplers.  In  the 
cable  television  systems  the  requirements  for  in-line  signal  amplification  are 
met  by  frequency  dependant  bidirectional  amplifiers  (low  and  high  pass  ampli¬ 
fiers  in  opposite  directions).  Thus  the  bus  is  in  reality  two  busses  operat¬ 
ing  in  different  directions  and  frequency  bands  on  one  cable  with  centralized 
control.  Neither  the  position  dependant  nor  the  "head  end"  bus  configurations 
is  applicable  to  future  avionics  installations. 

The  position  dependent  configuration  offers  little  growth  capability  and 
may  require  excessive  cabeling  to  attach  the  elements  to  their  correct  loca¬ 
tions  on  the  bus.  The  "head  end"  approach,  although  compatible  with  addition¬ 
al  processing  (e.g. ,  symbol  overlay  on  raster  scan  display  video),  requires  an 
excessive  hardware  investment.  For  each  exchange  of  information  between  two 
elements  a  receiver  and  transmitter  at  the  "head  end"  is  required  along  with 
the  excess  bandwidth  to  accommodate  the  two  channels  required  for  each  ex¬ 
change. 

The  directional  couplers  used  for  frequency  multiplex  busses  are  four 
port  devices  and  are  capable  of  coupling  in  either  direction  if  the  appropri¬ 
ate  input/output  port  is  selected  with  the  other  port  terminated.  Additional¬ 
ly,  dual  direction  coupler  configuration  capable  of  injecting  or  extracting 
signals  on  the  bus  in  both  directions  simultaneously  are  realizable  (however 
for  the  same  through  insertion  loss  (direct  path)  the  injection  or  extraction 
loss  is  approximately  6db  greater  than  for  a  single  directional  coupler).  Bus 


64 


Report  No.  NADC  81235-20 


designs  which  provide  dual  directional  capability  on  one  cable  using  either 
coupling  technique  are  feasible  as  long  as  the  length  of  the  bus  and  the  num¬ 
ber  of  couplers  is  constrained  to  alia?  operation  without  in-line  amplifiers. 
Using  the  switched  directional  coupler  ports,  the  simultaneous  transmission  of 
signals  to  both  up  and  down  stream  receivers  is  not  possible.  Using  the  non- 
directional  coupler  approach  severely  limits  the  size  of  the  bus  when  reason¬ 
able  dynamic  ranges  are  utilized  due  to  the  additional  6dB  injection  and  6dB 
extraction  losses.  Although  they  are  practical,  bus  designs  of  this  nature 
are  not  applicable  to  general  avionics  due  to  the  inherent  growth  limitations. 

The  growth  limitations  of  single  cable  dual  direction  busses  can  be  over¬ 
come  to  some  extent  by  the  inclusion  of  frequency  dependent  bidirectional  am¬ 
plifiers  (as  in  cable  television)  and  management  of  frequency  assignments 
based  on  the  required  direction  of  information  transfers.  Alternately,  two 
busses  without  in-line  amplifiers  can  be  connected  end  to  end  through  a  low 
pass  filter  (bus  length  at  lower  frequencies  may  be  extended  due  to  cable  loss 
characteristics)  with  low  frequency  assignments  used  for  inter  bus  exchanges. 
Again,  due  to  limitations  in  growth  potential  as  well  as  excessive  bus  manage¬ 
ment  requirements  neither  approach  is  considered  applicable  to  general  avion¬ 
ics  equipment. 

No  single  cable  frequency  multiplex  bus  configuration  with  general  appli¬ 
cability  to  avionics  equipment  has  been  identified.  Figure  5  illustrates  a 
two  cable  configuration  that  is  applicable.  As  illustrated  in  the  figure, 
with  a  two  cable  configuration  any  transmitter  can  send  information  to  any  re¬ 
ceiver.  As  noted  in  the  figure  but  not  recommended,  receivers  for  which  all 
transmitters  are  upstream  require  only  a  single  directional  coupler.  The  in¬ 
verse  is  also  true  for  transmitters.  In-line  amplification  is  feasible  and 
the  location  of  the  amplifier(s)  will  not  limit  the  bus  operation.  The  coup¬ 
lers  depicted  in  Figure  5  appear  complex,  however,  they  would  require  the  same 
number  of  components  as  the  dual  directional  coupler  configuration  discussed 
above  and  exhibit  3dB,  as  opposed  to  6dB,  additional  insertion/extraction  loss 
for  a  given  value  through  insertion  loss. 
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Figure  5  Two  Cable  Frequency  Multiplex  Bus 
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The  actual  Insertion  losses  encountered  by  a  frequency  multiplex  bus  de¬ 
pend  on  the  transmission  line  loss  as  well  as  the  coupling  values  utilized. 
Figure  6  compares  the  maximum  insertion  losses  for  three  bus  configurations. 
The  single  cable  directional  coupler  curve  is  applicable  to  Figure  4a.  and  is 
provided  for  reference  only.  The  two  cable  bus  coupler  curve  is  applicable  to 
the  configuration  in  Figure  5  and  could  be  reduced  by  3dB  with  no  impact  on 
bus  operation  if  receiver  directional  switching  were  utilized.  The  single  ca¬ 
ble  dual  direction  coupler  curve  illustrates  the  additional  insertion  loss  in¬ 
curred  in  order  to  simultaneously  inject  a  signal  in  two  directions  on  one  ca¬ 
ble.  The  value  of  n  represents  the  number  of  coupling  devices,  however,  since 
each  of  the  coupler  types  can  provide  two  simultaneous  input/output  connec¬ 
tions  the  total  number  of  devices  for  the  non  switched  configuration  could 
conceiveably  be  2  n.  The  insertion  loss  calculations  assume  equal  value  coup¬ 
lers  for  both  transmit  and  receive  applications  and  a  through  insertion  loss 
for  each  coupling  device  of  .45  dB  (actual  through  insertion  loss  equals  coup¬ 
ling  loss  plus  Insertion  loss).  For  each  value  of  n  the  optimum  coupling  fac¬ 
tor  for  each  of  the  3  configurations  to  minimize  the  worst  case  insertion  loss 
was  determined  and  the  resulting  worst  case  loss  is  plotted  in  Figure  6. 

Since  the  total  loss  difference  between  the  two  cable  bus  coupler  and  the 
single  cable  directional  coupler  configurations  can  easily  be  overcome  by  in¬ 
line  amplifiers,  the  two  cable  bus  coupler  configuration  is  considered  the 
preferred  configuration.  The  two  cable  configuration  allows  direct  comnunica- 
tion  between  any  two  elements  on  the  bus,  is  independent  of  coupler  placement, 
is  compatible  with  in  line  amplification  and  thus  expansion,  requires  no  more 
bandwidth  than  is  acually  necessary  for  the  transfer  of  information,  and  re¬ 
quires  only  management  of  frequency  assignments  (independent  of  direction). 

5. 3. 2. 2  Future  Requirements 

Frequency  multiplex  bus  distribution  is  compatible  with  almost  every  sig¬ 
nal  type  required  in  aircraft.  Once  installed  in  an  aircraft,  the  number  of 
potential  users  for  a  frequency  multiplex  bus  is  difficult  if  not  impossible 
to  forecast.  The  bandwidth  requirements  for  each  potential  use  is  likewise 
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N  =  number  of  couplers 


Figure  6 


Maximum  Coupling  Loss  for  frequency  mil  tipi  ex  bus 
optimized  for  the  number  of  couplers  versus  the 
transmitter  output  to  receiver  input  loss 
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not  predictable.  In  order  to  be  compatible  with  all  standard  interfaces  rec¬ 
ommended  in  this  report,  a  single  channel  information  bandwidth  of  17  MHz 
would  be  required  (video  interface  discussed  in  5.1.4).  Considering  pulse 
preservation,  amplitude  modulation  with  Double  Side  Band  (DSB)  transmission  is 
desirable,  hence,  a  17  MHz  information  banckfidth  would  require  34  MHz  of  bus 
bandwidth  (22  MHz  of  Ixis  bandwidth  for  vestigeal  sideband  of  sufficient  qual¬ 
ity  for  television  sync  and  video).  In  order  to  simplify  receiver  transmitter 
design,  the  34  MHz  bus  bandwidth  is  recommended  for  p‘»lse  as  well  as  sync  and 
video  information.  Operation  of  the  bus  with  each  channel  having  a  bandwidth 
of  34  MHz  would  be  inefficient  particularly  when  40  KHz  of  bus  bandwidth  is 
the  maximum  that  would  be  required  for  high  quality  voice. 

In  order  to  allow  some  optimization  of  bus  efficiency  for  what  is  basi¬ 
cally  an  undefinable  requirement,  the  following  bus  implementation  is  recom¬ 
mended.  The  bus  should  allow  for  3  different  bus  bandwidth  channels  namely, 

34  MHz  (17  MHz  information  using  DSB),  10  MHz  (5  MHz  information  using  DSB), 
and  1  MHz  (500  KHz  information  using  DSB).  The  arbitrarily  recommended  number 
of  channels  for  each  ban&ridth  is  seven.  This  would  result  in  a  bus  with  a 

total  of  21  channels  and  would  require  operation  in  the  500  MHz  to  1  GHz  fre¬ 

quency  band. 

It  is  anticipated  that  such  a  bus  would  be  used  to  satisfy  a  number  of 
different  interface  requirements  as  for  example,  signals  intended  for  radio 
frequency  transmission  as  well  as  signals  for  cockpit  display  of  navigation 
information.  Such  applications  would  have  Red/Black  implications,  for  example 
it  would  not  be  desirable  to  inadvertantly  transmit  navigation  way  point  in¬ 
formation.  However,  it  may  be  desirable  to  view  simultaneously  a  video  dis¬ 
play  in  the  cockpit  while  transmitting  the  same  information  via  data  link.  As 

a  potential  solution  to  this  problem  it  is  recommended  that  the  three  differ¬ 

ent  bandwidth  channels  be  spread  over  the  operating  frequency  of  the  bus. 
Equipment  capable  of  radio  frequency  transmission  could  then  be  required  not 
to  Implement  processing  capability  for  two  of  the  10  MHz  and  34  MHz  channels 
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operating  at  the  upper  frequency  channels.  These  channels  could  then  be  uti¬ 
lized  exclusively  for  processing  Red  signals.  If  further  restrictions  for  a 
particular  aircraft  application  were  required  low  pass  or  band  pass  filters 
could  be  installed  at  the  appropriate  points  along  the  bus  to  preclude  trans¬ 
mission  of  Red  signals.  The  recommended  implementation  would  require  addi¬ 
tionally  that  software  fail-safe  modes  in  the  frequency  channel  assignments, 
similar  to  the  terminal  address  restrictions  being  considered  for  Red/Black 
MIL-STD-1553  applications,  be  implemented. 

The  incorporation  of  frequency  multiplex  busses  in  future  avionics  in¬ 
stallations,  for  which  there  are  redundancy  requirements,  deserves  special 
consideration.  The  provisions  for  true  redundancy  in  frequency  multiplex  bus 
applications  would  be  similar  to  any  other  redundancy  implementation,  i.e., 
standby  equipment  capable  of  performing  the  function  for  which  redundancy  is 
required.  In  general,  some  of  the  equipment  interfaced  to  the  multiplex  hus 
would  be  capable  of  performing  the  same  functions  (e.g.,  multi-purpose  cockpit 
displays  or  video  data  processors),  hence  degraded  mode  capability  as  opposed 
to  redundancy  can  be  maintained  with  the  failure  of  the  equipment.  It  is  en¬ 
visioned  that  in  many  cases  the  conversion  of  bus  information  back  to  baseband 
will  be  performed  within  the  equipment  (e.g.,  in  the  cockpit  displays),  hence, 
a  baseband  converter  failure  would  be  a  display  failure  and  degraded  mode  ca¬ 
pability  would  be  available  using  an  alternate  display.  In  this  case  only  the 
bus  coupler  and  cabeling  would  be  required  to  be  redundant.  There  are  other 
applications  where  a  single  bus  to  baseband  converter  might  be  utilized  for 
two  or  more  equipment  items,  however,  if  redundancy  were  required  for  one 
function  then  redundant  bus  to  baseband  converters  would  be  required  and  it 
would  be  just  as  simple  to  make  the  converter  part  of  the  equipment.  It  is 
recommended  that  frequency  multiplex  bus  signal  converters  be  made  part  of 
each  piece  of  equipment  unless  a  determination  can  be  made  that  there  are  no 
redundancy  requirements  for  the  equipment.  The  part  of  the  equipment  recom¬ 
mendation  does  not  necessarily  mean  the  converter  is  contained  within  the 
equipment,  but,  rather  it  could  be  satisfied  with  a  dedicated  converter  for 
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each  piece  of  equipment.  If  the  recommendation  Is  followed  then  only  redun¬ 
dant  bus  couplers  and  cabellng  should  be  required. 

The  two  cable  bus  configuration  recommended  offers  some  Inherent  redun¬ 
dancy  In  that  a  loss  of  transmission  capability  in  one  direction  will  not  In 
general  affect  the  transmission  in  the  opposite  direction,  however,  this  fea¬ 
ture  will  not  permit  true  redundant  operation.  It  is  recommended  that  redun¬ 
dancy  be  achieved  by  the  installation  of  two  separate  two  wire  busses.  All 
equipment  utilizing  frequency  multiplexing  should  interconnect  to  one  bus. 

All  mission  essential  equipment  should  be  switch  connectable  to  the  redundant 
bus.  Simultaneous  coupling  to  both  busses  with  almost  no  insertion  loss  im¬ 
pact  is  feasible,  however,  due  to  interference  on  both  busses  that  can  be  gen¬ 
erated  by  coupler  isolated  port  leakage  and  the  dependence  of  coupler  perfor¬ 
mance  on  matched  terminations  on  both  busses,  this  technique  is  not  recommen¬ 
ded.  Where  redundant  bus  connection  is  required,  two  separate  bus  cables 
should  be  brought  to  the  equipment  interface  and  bus  switching  performed  in¬ 
ternal  to  the  equipment. 

Normal  bus  operation  should  allow  utilization  of  the  redundant  bus  to  ex¬ 
pand  overall  capability.  This  can  be  accomplished  by  allowing  the  sum  of  mis¬ 
sion  essential  and  non  mission  essential  bus  utilization  to  exceed  bus  capa¬ 
city  so  long  as  the  total  mission  essential  requirement  is  less  than  the  bus 
capacity.  For  example,  assume  the  mission  essential  equipment  required  70%  of 
bus  capacity  and  the  non  mission  essential  equipment  required  40 X  of  bus  capa¬ 
city.  Further,  during  normal  operation  assume  the  main  bus  carries  half  the 
mission  essential  and  all  the  non  mission  essential  signals  (1/2  70%  +  40%  * 
75%  of  bus  capacity)  and  the  redundant  bus  carried  the  other  half  of  the  mis¬ 
sion  essential  signals  (1/2  70%  =  35%  of  bus  capacity).  A  failure  on  the  main 
bus  would  require  switchover  so  the  redundant  bus  carried  all  of  the  mission 
essential  signals.  This  would  result  in  total  loss  of  the  non  mission  essen¬ 
tial  signals.  A  failure  on  the  redundant  bus  would  require  deletion  of  non 
mission  essential  signals  in  order  to  carry  the  necessary  signals.  The  effect 
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of  either  failure  would  be  the  same  i.e.,  deletion  of  non  mission  essential 
functions.  Allowing  this  mode  of  operation  maximizes  hardware  utilization. 

Control  of  the  frequency  multiplex  bus  should  be  accomplished  via  the 
MIL-STD-1553  bus  for  a  number  of  reasons.  The  serial  data  bus  will  provide 
redundant  control  as  well  as  a  means  of  controlling  Red/Black  frequency  as¬ 
signments.  The  1553  bus  will  also  provide  an  available  link  between  different 
subsystems  or  groups  of  subsystems.  The  control  function  should  be  performed 
by  an  aircraft  computer  rather  than  within  any  one  subsystem  in  order  to  allow 
integration  of  different  equipment  in  different  aircraft, 

6.0  RECOMMENDATIONS 


Specific  recommendations  for  actions  or  policies  that  can  be  implemented 
to  achieve  the  ultimate  goals  of  the  AVCS  program  are  presented  in  this  sec¬ 
tion.  The  recommendations  given  are  based  on  considerations  of  all  the  areas 
discussed  in  this  report.  Negative  comments  or  deficiencies  noted  in  other 
sections  of  this  report  are  countered  with  positive  recommendations  and  a  ref¬ 
erence  to  sections  of  this  report  where  italicized  comments  were  made.  Addi¬ 
tionally,  recommendations  made  in  other  portions  of  this  report  are  repeated 
to  provide  a  consolidated  list  and  indicate  a  method  of  implementing  the  rec¬ 
ommendation.  Specific  recoramedations  regarding  AIDS,  USA,  TIES,  and  mission 
equipment  are  not  repeated.  The  reader  is  referred  to  A. 3. 2,  4.3.3,  4.3.4, 
and  4.3.5  respectively  for  recommendations  regarding  these  elements. 

6.1  MODIFICATIONS  TO  EQUIPMENT  PROCUREMENT  PRACTICES 

6.1.1  General 


The  implementation  of  individual  recommendations  for  revised  military 
standards,  considerations  to  be  applied  to  ongoing  efforts,  and  new  develop¬ 
ments  do  not  in  general  present  procurement  problems.  The  procurement  of  new 
equipment  compatable  with  the  architectural  philosophy  of  Section  4.0  presents 
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both  political  and  procurement  problems.  The  architecture  presented  in  Sec¬ 
tion  4.0  was  generated  from  a  system  engineering  point  of  view  with  the  system 
being  the  core  avionics.  This  approach  leads  (correctly)  to  functional  allo¬ 
cations  for  pieces  of  equipment  and  not  to  requirements  for  individual  subsys¬ 
tems  (i.e.,  the  equipment  no  longer  represents  a  stand  alone  system  or  whole). 
For  example,  all  crew  interfaces  for  GFE  core  avionics  are  provided  via  the 
Display  and  Control  subsystem,  thus,  the  radio  frequency  control  is  not  part 
of  the  radio.  In  order  to  procure  a  radio  it  must  be  tested  and  in  order  to 
test  the  equipment  a  frequency  control  is  required.  The  ramifications  of  this 
problem  are  more  severe  for  other  “subsystems".  The  procurement  of  GFE  iner¬ 
tial  sensors  and  limited  capability  Navigation  Processors  that  don't  tell  you 
“how  to  get  home"  (waypoint  and  dead  reckoning  computations  done  in  the  CFE 
Mission  Computer)  makes  the  equipment  appear  less  useful  (even  though  it  may 
actually  be  more  so)  than  an  inertial  navigation  "system”.  The  overall  per¬ 
formance  of  the  core  avionics  system  as  well  as  the  individual  equipment  items 
procured  as  GFE  cannot  be  evaluated  until  the  integration  with  CFE  hardware 
and  software  is  accomplished  (e.g. ,  navigation  accuracy  is  a  function  of  the 
quality  of  the  sensor  and  Navigation  Processor  hit  is  also  a  function  of  the 
quality  of  the  software  in  the  Mission  Computer  which  may  be  supplied  by  a 
different  contractor). 

The  "who's  at  fault  if  it  doesn't  work"  problem  is  not  new  and  is  not 
tied  to  the  architecture  of  Section  4.0.  If  the  benefits  of  common  avionics 
are  to  be  realized  then  common  equipment  must  satisfy  the  least  common  denom¬ 
inator  for  all  the  platforms.  The  procurement  of  this  equipment  is  manageable 
if  performance  requirements  are  stated  relative  to  Interface  information  qual¬ 
ity  and  if  detailed  Interface  and  control  requirements  are  established.  The 
demonstration  of  equipment  can  be  accommodated  by  simultaneous  development  of 
support  equipment  with  dynamic  test  capability  and,  if  necessary,  brassboard 
quality  controls  and  displays  for  flight  demonstrations.  The  generation  of 
procurement  packages  of  sufficient  detail  will  place  a  larger  system  engineer¬ 
ing  burden  and  responsibility  on  the  government  but  represents  a  cost  that  can 
yield  significant  benefits.  Of  equal  importance  is  self  restraint  on  the  pa’-t 
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of  the  government  to  limit  the  requirements  to  those  of  the  least  common  de¬ 
nominator  without  designing  the  entire  system  and  thus  stifling  the  ability  of 
the  airframe  contractor  to  meet  the  weapons  system  requirements  using  GFE. 

The  interface  detail  required  for  equipment  adapted  via  an  AIU  module 
should  be  stated  relative  to  the  output  of  the  equipment  developers  side  of 
the  AIU  module  (see  6.4.2. 1.3)  with  no  detail  requirements  for  the  AIU  to 
equipment  interface  other  than  a  description  of  the  information  to  be  accessed 
from  the  AIU.  For  example,  if  it  is  desired  to  tune  a  radio  via  a  serial  dig¬ 
ital  bit  stream  then  that  is  the  requirement  that  should  be  stated  for  the 
AIU.  If  the  contractor  chooses  to  convert  this  to  parallel  data  within  his 
half  of  the  AIU  he  should  be  free  to  do  so.  This  approach  is  consistent  with 
the  least  common  denominator  in  that  another  aircraft  that  may  require  paral¬ 
lel  data  can  be  accommodated  with  only  a  different  AIU  conversion.  It  is  also 
consistant  with  minimizing  the  excess  hardware  within  the  subsystem  since,  any 
interface  specified  for  the  AIU  to  equipment  connection  would  most  likely  re¬ 
quire  some  form  of  conversion  within  the  equipment  to  accommodate  the  equip¬ 
ment  mechanization  (e.g.,  fine  and  coarse  tune  signals).  Equipment  Intended 
for  Interface  via  an  AIU  should  state  the  interface  method  explicitly.  Test¬ 
ing  of  AIU  interfaced  equipment  should  be  accommodated  using  prototype  half 
AIU  modules  with  less  than  half  of  the  module  capacity  utilized  in  order  to 
allow  for  aircraft  peculiar  requirements. 

Equipment  that  has  the  potential  for  multipurpose  use  (e.g.,  radio  trans¬ 
mitter/receiver  assets)  should  be  required  to  be  packaged  as  spearate  units 
(deficiency  noted  in  5.2).  Additionally,  multipurpose  equipment  specifica¬ 
tions  should  be  reviewed  for  TIES  comparability  prior  to  initial  development. 

The  equipment  specification  should  detail  the  requirements  for  nultiplat- 
forra  application.  Consider  the  time  multiplex  bus  address  programming  for 
each  piece  of  equipment  via  the  aircraft  interconnect  that  is  recommended  in 
6. 2. 3. 1.1.  This  implementation  requires  that  provisions  must  be  made  within 
the  equipment  for  variable  address  assignment  for  associated  equipment.  For 
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example,  If  it  Is  required  that  the  two  Display  and  Control  Processors  commu¬ 
nicate  with  each  other  over  the  mission  computer  time  multiplex  bus  then  pro¬ 
vision  must  be  made  within  each  processor  to  accept  and  store  the  address  of 
the  other  processor  from  the  Mission  Computer  as  part  of  the  power  up  se¬ 
quence. 

In  order  to  achieve  the  maximum  benefit  from  common  equipment  the  devel¬ 
opment  of  a  single  piece  of  equipment  must  consider  the  capabilities  of  other 
equipment  as  available  assets.  For  example,  for  built-in  test  purposes  an  on¬ 
board  radiated  interference  signal  is  a  BIT  oscillator  if  the  blanking  signal 
is  disabled  during  the  test.  Such  implementations  are  possible  for  RF  checks 
of  IFF  transponder/interrogator,  IFF/TACAN,  Radio/ ADF /DDL,  and  EW/Radar  Bea¬ 
con/Beacon  Augraenter/ ILS  if  signal  acceptance  criteria  in  BIT  were  specified 
to  be  compatible. 

6.1.2  Functional  Interfaces 


It  is  recommended  that  the  practice  of  developing  replacement  equipment 
which  is  a  "form,  fit,  functional  replacement”  for  existing  equipment  be  dis¬ 
continued  particularly  in  regard  to  interfaces.  Producing  a  subsystem  that 
has,  for  example,  synchro  outputs  to  accommodate  older  aircraft  and  a  digital 
output  for  newer  aircraft  means  that  every  aircraft  requires  increased  subsys¬ 
tem  acquisition  costs;  increased  size,  weight,  power  consumption,  cooling;  and 
decreased  reliability  (more  parts)  as  well  as  the  potential  for  inconsequen¬ 
tial  failure  detections  (faulty  synchro  output  detected  in  a  digital  air¬ 
craft).  Although  it  is  politically  attractive  to  advertise  a  development 
equipment  as  a  direct  replacement,  it  almost  never  actually  is.  New  equipment 
provides  new  capability  which  most  often  requires  aircraft  integration  to 
allow  it's  use.  Equipment  that  provides  the  lowest  common  denominator  in  ca¬ 
pability  is  the  most  likely  to  receive  universal  use.  When  an  additional  in¬ 
terface  must  be  provided  (e.g.,  synchro  output)  this  interface  should  be  pro¬ 
vided  by  a  separate  element  (e.g.  AID)  which  can  be  GFE  or  CFE.  This  approach 
has  a  short  terra  logistics  burden,  however,  if  the  least  common  denominator 
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element  is  universally  applied  the  long  term  result  will  be  a  reduced  logis¬ 
tics  burden. 

Although  somewhat  contrary  to  the  above  it  is  recommended  that  specifica¬ 
tions  for  certain  functional  interfaces  be  generated  and  incorporated  in  de¬ 
velopment  specifications  for  all  avionics  equipment  by  reference.  The  func¬ 
tional  interfaces  should  be  required  if  applicable,  regardless  of  whether  they 
are  needed  for  operation  of  the  subsystem  under  development.  These  interfaces 
are  required  to  allow  a  certain  degree  of  commonality  for  aircraft  intercon¬ 
nect  requirements  as  well  as  for  greater  functional  commonality. 

6. 1.2.1  Blanking 

For  electromagnetic  comp at ability  and  general  integration  purposes,  all 
subsystems  that  transmit  or  receive  energy  in  the  frequency  range  of  30  MHz  to 
32  GHz  should  be  required  to  incorporate  blanking  interfaces.  The  recommended 
interface  is  a  ten  bit  code  with  each  bit  representing  an  octave  or  a  suboc¬ 
tave  above  or  below  1  GHz.  The  lower  two  frequency  ranges  should  be  rounded 
off  to  30-60  MHz  and  60-125  MHz.  Each  subsystem  need  only  generate  or  accept 
the  applicable  bits  of  the  code  and  should  utilize  the  standard  dedicated 
digital  interface  of  6.2. 1.2.1.  The  blanking  interval  should  be  designated  as 
a  binary  1  or  Mark  state  to  accommodate  fail  safe  provisions.  For  pulse  modu¬ 
lated  transmitters,  the  blanking  interval  should  be  present  during  the  entire 
transmitted  pulse  plus  200  nsec  to  allow  for  transmission  line  ringing.  The 
specification  should  require  the  blanking  signal  to  lead  the  actual  RF  energy 
for  transmitter  outputs  in  order  to  accommodate  distribution  delays  for  the 
blanking  signal.  Subsystems  requiring  higher  frequency  resolution  than  pro¬ 
vided  by  the  specified  blanking  inputs  should  generate  and  accept  the  speci¬ 
fied  inputs  in  addition  to  any  finer  resolution  signals.  This  requirement  is 
considered  necessary  in  order  to  accommodate  other  subsystems  that  cannot  pro¬ 
vide  the  higher  resolution.  The  line  driver  for  each  blanking  output  should 
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be  monitored  internal  to  the  subsystem  to  insure  that  artificial  blanking  sig¬ 
nals  due  to  a  line  driver  failure,  which  may  disable  another  subsystem,  cause 
all  blanking  outputs  for  that  line  driver  to  be  removed. 

6. 1.2.2  Clock 

Each  subsystem  that  accepts  or  generates  digital  information  other  than 
binary  state  information  should  be  required  to  accept  a  square  wave  master 
clock  input.  A  clock  frequency  of  250  KHz  (4  usee  Pulse  Repetition  Period 
( PRP )  or  500  kilobaud)  is  recommended  in  6. 4. 2. 4.  All  digital  interfaces 
should  be  required  to  operate  at  frequencies  that  are  simple  derivitives  of 
the  clock  frequency.  The  subsystems  should  be  required  to  operate  with  or 
without  the  clock  input,  however,  when  the  clock  signal  is  present  the  digital 
interface  operation  should  be  synchronized  to  the  master  clock  within  12.5%  of 
the  nominal  PRP  of  the  interface.  When  the  clock  input  is  not  present  the 
subsystems  should  be  capable  of  maintaining  internal  clock  operation  with 
synchronization  provided  by  MIL.-STD-1553  serial  bus  Synchronize  mode  commands. 
The  imposition  of  these  requirements  will  allow  greater  future  integration  by 
providing  a  mechanism  for  skew  compensation,  allowing  monitoring  of  existing 
interfaces  by  future  subsystems,  and  providing  standard  operating  rates. 

6. 1.2.3  External  Control 

In  order  to  achieve  functional  commonality  subsystems  must  be  capable  of 
performing  more  than  one  operation  even  though  they  are  built  to  perform  only 
one  function.  Capability  to  perform  more  than  one  function  can  be  gained  by 
requiring  access  to  subsystem  assets.  Two  areas  where  this  capability  is  rea¬ 
lizable  by  specifying  the  requirement  in  the  procurement  of  the  subsystem  have 
been  identified. 
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6. 1.2.3. 1  Amplitude  Modulation 

All  subsystems  capable  of  transmitting  or  receiving  pulse  modulated  RF 
signals  should  be  required  to  provide  access  to  the  transmitter  receiver  as¬ 
sets.  For  subsystems  with  transmitter  capabilities,  a  command  override  input 
to  the  subsystem  should  allow  external  modulation  of  the  transmitter  using 
either  the  video  interface  recommended  in  6. 2. 1.4  for  transmitters  with  linear 
capabilities  or  using  the  digital  interface  recommended  in  6.2. 1.2.2  for 
transmitters  with  fixed  power  output.  For  subsystems  with  receiver  capabili¬ 
ties  a  single,  parallel  output  of  detected  video  interfaced  using  either  the 
video  output  recommended  in  6. 2. 1.4  for  receivers  with  proportional  amplitude 
characteristics  or  the  digital  interface  recommended  in  6.2. 1.2.2  for  recei¬ 
vers  with  pulse  present  capabilities  should  be  required.  Additional  transmit¬ 
ter  or  receiver  capabilities  built  into  the  subsystem  to  accommodate  general 
purpose  interfaces  are  not  recommended  unless  they  can  be  tied  to  a  specific 
requirement.  As  an  example  of  the  capability  that  could  result  from  the  use 
of  such  interfaces,  if  the  amplitude  modulation  interfaces  were  included  along 
with  some  frequency  control  interfaces  in  modern  Deceptive  Electronic  Counter¬ 
measures  ( DECM)  Subsystems  (e.g. ,  AN/ALQ-126B  and  AN/ALQ-165)  the  transmitter 
and  receiver  hardware  for  radar  beacon  equipment  (e.g.,  AN/APN-154  or  AN/APN- 
202)  could  be  eliminated.  The  example  given  is  impractical  only  because  DECM 
equipment  is  not  carried  on  all  aircraft  or  even  in  every  flight  of  provi¬ 
sioned  aircraft. 

6. 1.2. 3. 2  IF  Access 

All  radio  communications  equipment  utilizing  more  than  one  IF  conversion 
should  be  required  to  provide  external  access  to  the  IF  for  both  receive  and 
transmit  capability.  This  interface  would  allow  external  equipment  to  utilize 
the  transmitter  and  receiver  assets.  The  first  IF  should  be  required  to  be 
compatible  with  the  recommended  interface  in  6. 2, 1.5  and  will  then  also  be 
compatible  with  the  multiplex  switch  network  recommended  6.4.2. 3.  Access  to  a 
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single  IF  interface  for  both  transmit  and  receive  should  be  provided  by  a 
command  override  receive  or  transmit  Input  to  the  subsystem. 

The  use  of  both  the  IF  access  and  IF  multiplex  switching  allows  sharing 
of  both  the  "front"  and  "back"  end  of  radio  equipment  (see  Figure  2  )  in  order 
to  reduce  the  proliferation  of  equipment,  enable  the  sharing  of  assets  to 
maintain  capability  in  the  presence  of  a  failure,  and  accommodate  future  re¬ 
quirements  by  replacing  only  one  end  of  the  equipment.  If  available  in  exist¬ 
ing  equipment  today,  this  interface  would  allow  elimination  of  the  auxiliary 
UHF  radio  receiver  by  utilization  of  the  redundant  radio  assets  while  provid¬ 
ing  greater  transmit/receive  redundancy  capability  than  is  currently  available 
even  with  the  extra  radio. 

6.2  STANDARDS  CHANGES /ADDITIONS 

In  order  to  achieve  commonality,  growth  capability,  and  technology  trans¬ 
parency  military  standards  must  be  applied  to  avionics  developments  (defi¬ 
ciency  noted  in  5.1).  The  success  of  this  approach  is  best  exemplified  by 
MIL-STD-1553.  Once  established,  standard  application  must  be  enforced  vigor¬ 
ously,  however,  provisions  must  be  made  to  accommodate  the  legitimate  needs  of 
specialized  subsystems.  The  application  and  enforcement  of  Qualified  Parts 
Lists  (QPL)  and  the  Standard  Electronic  Module  Program  (SEMP)  have  significant 
effects  on  logistics  support,  however,  they  do  not  assure  that  avionics  archi¬ 
tectural  compatibility  requirements  will  be  met  in  today's  changing  technology 
environment.  Subsystems  under  development  require  the  use  of  nonstandard 
parts  in  order  to  meet  both  performance  and  packaging  requirements.  There  is 
no  reason  to  believe  this  trend  will  not  continue  or  be  applicable  to  inter¬ 
face  components.  The  use  of  detailed  standards  is  not  a  cure-all  for  common¬ 
ality  but  standards  can  effect  compatibility  with  a  large  degree  of  technology 
transparency.  The  detail  of  the  standards  should  be  sufficient  to  Insure  com¬ 
patibility  between  designs  built  to  the  same  standard  but  no  more  restrictive 
than  13  absolutely  necessary.  Once  developed,  it  is  recommended  the  NAVAIR 
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immediately  and  unilaterally  adopt  the  recommended  standards  in  all  cases 
where  conflicts  with  existing  railitary/international  standards  do  not  exist. 

In  order  to  make  the  conversion  to  standard  interfaces  effective  in  terms  of 
future  aircraft  integration  capabilities,  it  is  further  recommended  that  these 
standards  be  applied  to  all  Navy  avionics  developments  including  those  of  the 
AVCS  program.  The  following  recommendations  for  standards  are  made. 

6.2.1  Dedicated  Interfaces 


It  is  recommended  that  a  military  standard  for  dedicated  interfaces  be 
generated.  Additional  standards  for  each  specific  type  of  interface  should  be 
generated  as  appendices  or  as  dash  amendments  to  the  basic  standard  (as  with 
MIL-STD-188) .  The  quantity  of  additional  standards  should  be  restricted  by 
generating  standards  only  for  a  general  type  of  interface.  If  the  quantity  of 
standards  is  not  restricted,  the  standards  cannot  accon^lish  the  purpose  of 
compatibility  between  subsystems. 

6.2. 1.1  Binary  Interfaces 

Standards  for  only  three  types  of  binary  Interfaces  are  recommended. 

6. 2. 1.1.1  Power  Input 

One  on/off  interface  per  subsystem  should  be  allowed.  The  interface 
should  operate  from  a  switched  ground  return  to  28  V  dc  (maximum  current  0.2 
ampere)  as  discussed  in  5. 1.1.1. 

6. 2. 1.1. 2  Current  Sink  Output 

High  lmpedance/low  impedance  outputs  capable  of  sinking  0.2  ampere  from 
28  V  dc  should  be  allowed  for  cockpit/station  warning  alarms.  Subsystems 
should  provide  only  continuous  outputs  with  blinking  applied  in  the  instrument 
panel. 
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6. 2. 1.1. 3  Discrete  Input/Output 

All  other  binary  Interfaces  should  be  Identical  to  one  of  the  two  digital 
Interfaces  recommended  on  6. 2. 1.2. 

6. 2. 1.2  Digital  Interfaces 

Standards  for  only  two  types  of  dedicated  digital  Interfaces  are  recom¬ 
mended  at  this  time. 

6. 2. 1.2.1  Line  Driver/Receiver 

It  is  recommended  that  a  general  military  standard  applicable  to  all  Navy 
avionics  equipment  that  adopts  EIA-RS-422A  without  modification  be  generated 
(deficiency  noted  in  5. 1.2.1).  The  standard  should  require  line  drivers  to 
operate  at  up  to  a  10  MHz  rate  with  multiple  line  receivers  spaced  anywhere 
from  0  to  150  feet  from  the  driver  with  all  line  receivers  utilizing  input 
terminations  for  ac  impedance  matching  and  with  or  without  internal  fail  safe 
provisions  incorporated  (deficiency  noted  in  5. 1.2.1).  This  requirement  could 
be  stated  in  terms  of  compatibility  with  a  specific  receiver  chip  (e.g.,  MIL- 
M-38510/104A-04)  and  specified  terminations  and  if  necessary  should  reduce 
the  number  of  parallel  receivers  from  10  as  required  by  EIA-RS-422A  to  a  mini¬ 
mum  of  six  (deficiency  noted  in  5. 1.2.1).  The  potential  of  increasing  the 
number  of  line  recede rs  beyond  10  (limit  imposed  by  EIA-RS-422)  by  utilizing 
single  point,  fail  safe  biasing  (pull  up-pull  dcxm  resistors)  should  be  in¬ 
vestigated  and  is  recommended  as  part  of  the  augmented  bus  development  in 
6. 4. 1.1.  In  order  to  allow  for  future  integration  the  standard  should  require 
initial  designs  to  be  configured  such  that  no  more  than  70Z  of  the  maximum 
number  of  parallel  line  receivers  is  driven  by  a  single  line  driver.  Line  re¬ 
ceiver  requirements  should  be  stated  in  terms  of  compatability  with  the  maxi- 
mumly  loaded  line  driver. 
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6. 2. 1.2. 2  Tri-state  Line  Driver 

It  is  recommended  that  a  general  military  standard,  applicable  to  all 
Navy  avionics  equipment  for  a  tri-state  line  driver  be  generated.  The  line 
driver  should  be  a  one  for  one  replacement  for  the  line  driver  of  6. 2. 1.2.1 
(e.g.,  MIL-M-38510/104A-05)  and  be  compatible  with  all  requirements  for  the 
line  receiver  loads  of  6. 2. 1.2.1.  For  transceiver  operation  (half  duplex), 
the  Interface  should  allow  "wire  or"  of  the  tri-state  line  driver  and  line 
receiver  external  to  the  equipment. 

Utilization  of  the  tri-state  line  driver  should  be  required  in  lieu  of 
the  driver  of  6. 2. 1.2.1  in  all  cases  where  the  information  supplied  by  the 
line  driver  can  be  utilized  in  response  to  an  external  input  from  another  sub¬ 
system.  This  implementation  mechanism  is  directly  compatible  with  bus  re¬ 
quirements  and  offers  growth  capability  when  non-bus  interfaces  are  employed. 
For  non-bus  interfaces  a  tri-state  line  driver  makes  the  line  receiver  end  of 
the  interface  compatible  with  multipurpose  uses. 

6. 2. 1.3  Analog  Interfaces 

Standards  for  only  two  types  of  analog  interfaces  are  recommended  at  this 

time. 


6. 2. 1.3.1  Amplitude 

A  general  military  standard  applicable  to  all  Navy  avionics  elements  for 
proportional  amplitude  interfaces  should  be  established.  The  standard  should 
allow  one  unipolar  type  (0  to  +10  V  recommended)  and  one  bipolar  type  (-5  to 
+5  V  recommended),  amplitude  proportional  Interface  which  is  compatible  with 
analog/digital  sampling  or  digital/analog  conversion. 
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6.2. 1.3.2  Phase 

A  general  military  standard  applicable  to  all  Navy  avionics  elements  for 
proportional  phase  Interfaces  should  be  established.  The  standard  should  al¬ 
low  for  one  low  level  type  (26  V  (11.8  V  signal))  and  one  high  level  type  (115 
V  (90  V  signal))  phase  proportional  interface  which  is  compatible  with  synchro/ 
digital  sampling  or  digital  to  synchro  conversion. 

6.2. 1.4  Video  Interfaces 

It  is  recommended  that  a  general  military  standard  applicable  to  all  Navy 
avionics  equipment  be  developed  for  a  17  MHz  bandwidth  video  interface.  The 
interface  should  accommodate  both  pulse  video  (120  nsec  pulse  width  minimum  and 
40  nsec  rise  time  maximum)  and  composite  sync  and  video  raster  scan  signals 
(actual  requirement  =  16.9  MHz  for  1023  line  (with  equal  vertical  and  horizon¬ 
tal  resolution)  4:3  aspect  ratio  sync  and  video  display).  Group  delay  require¬ 
ments  should  also  be  established  to  accommodate  multichannel  pulse  comparison 
systems. 


6.2. 1.5  Modulated  Carriers 

As  discussed  in  5.1.5  general  standards  for  modulated  carrier  interfaces 
are  not  recommended  because  of  potential  subsystem  performance  considerations. 
A  military  standard  applicable  to  all  Naval  avionic  radio  comminications 
equipment  for  IF  interfaces  is  recommended.  The  recommended  interface  is  a  70 
MHz  IF  with  a  10  MHz  bandwidth  at  a  nominal  -20dBm  signal  level. 

6.2.2  Switched  Interfaces 


Because  of  the  specialized  nature  of  switched  interfaces  as  discussed  in 

5.2  it  is  recommended  that  standards  for  switched  interfaces  not  be  adopted. 
However,  as  part  of  the  overall  interface  standard  it  should  be  required  that 
all  switching  functions  be  performed  by  a  standard  interface  and  that  switch¬ 
ing  networks  be  used  only  to  switch  standard  interface  signals. 
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6.2.3  Multiplexed  Interfaces 
6.2. 3.1  Time  Multiplex 

In  addition  to  the  following  standard  revisions  the  development  of  an 
augmented  MIL-STD-1553  data  bus  and  an  associated  standard  is  recommended  in 
6.4.1. 1. 


6.2.3. 1.1  Recommended  Revisions  to  MIL-STD-1553 

a.  The  maximum  number  of  data  words  per  tansfer  should  remain  at  32  for 
serial  bus  transfers  but  allowance  should  be  made  to  incorporate 
larger  transfers  via  a  parallel  bus  as  indicated  under  the  recom¬ 
mended  developments  (deficiency  noted  in  5. 3. 1.2). 

b.  The  standard  should  be  revised  to  require  that  terminal  addresses  be 
programmable  by  grounding  of  five  pins  by  aircraft  wiring  in  a  man¬ 
ner  consistent  with  the  AN/ARC-132  convention  (deficiency  noted  in 
5. 3. 1.2). 

c.  The  standard  should  be  revised  to  require  that  both  long  and  short 
stub  interconnects  be  provided  for  each  element.  This  is  necessary 
to  allow  flexibility  of  installation  in  different  weapon  systems. 

d.  The  subaddress  field  of  the  Command  Word  should  be  specified  in  or¬ 
der  to  gain  a  larger  degree  of  commonality  between  weapon  system 
applications.  The  specification  of  the  subaddress  field  should  be 
accomplished  considering  all  known  applications  to  provide  maximum 
compatibility  with  existing  uses.  The  latitude  required  for  system 
design  can  be  achieved  using  single  data  word  transfers  (16  bits 

of  control)  along  with  the  Command  Word. 
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e.  The  specif icaiton  of  the  subaddress  field  or  an  addition  to  the  mode 
command  field  should  alia*  for:  transmission  of  one  and  two  data 
words  in  response  to  a  vector  word  mode  command,  transmission  and 
reception  over  one  or  more  alternate  busses  (parallel  bus  for  exam¬ 
ple),  and  transmit  new  status  word  to  allow  for  service  requrests  as 
part  of  a  normal  polling  cycle. 

6. 2. 3. 2  Frequency  Multiplex 

The  establishment  of  a  military  standard  for  signal  distribution  by  fre¬ 
quency  multiplex  is  recommended.  This  standard  should  be  generated  during  the 
interface  development  recommended  in  6. 4. 1.2. 

6.3  CONSIDERATIONS  FOR  ONGOING /PLAN NED  DEVELOPMENTS 

6.3.1  Intercommunications  System  (ICS) 

The  ICS  subsystem  being  developed  under  the  AVCS  program  should  include 
the  following:  personnel  equipment  with  redundant  speakers  and  microphones 
that  meet  TEMPEST  requirements,  redundant  Comnunications  Security  (COMSEC) 
switching  units,  and  self-compensating  (one  volume  control  for  all  functions) 
redundant  audio  switching  and  amplification  units.  This  subsystem  should  be 
designed  to  be  modularly  expandable  to  accommodate  one  or  more  crew  members. 
Operator  controls,  including  COMSEC  switching,  should  be  redundant  and  self 
contained  in  the  ICS  subsystem.  General  audio  summing  should  not  be  part  of 
the  system.  The  system  should  allow  for  dual  inputs/outputs  of  audio  for  each 
redundant  path  and  allow  for  a  single  combined  tone  input  in  each  redundant 
path. 

6.4  NEW  DEVELOPMENTS 

6.4.1  Interfaces 
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6. 4.1. 1  Augmented  MIL-STD-1553  Bus 

The  utilization  of  serial  data  busses  configured  according  to  MIL-STD- 
1553  is  increasing  and  represents  a  substantial  investment  on  the  part  of  the 
Navy.  This  bus  system  has  several  limitations  in  terms  of  its  general  appli¬ 
cation  as  a  digital  data  distribution  medium  (deficiency  noted  in  5. 3. 1.2). 

The  continued  proliferation  of  1553  data  busses  will  yield;  multiple  bus  con¬ 
figurations  with  multiple  bus  controllers  to  overcome  the  shortfalls  of  a 
single  (redundant  or  not)  main  bus,  and  bus  utilization  fine  tuned  to  the  ini¬ 
tial  system  design  thus  prohibiting  the  use  of  any  inherent  growth  capability 
(i.e.  ,  MIL-STD-1553  compliance  in  the  letter  and  not  the  intent).  The  Navy 
can  protect  the  existing  investment  in  1553  bus  hardware  while  providing  addi¬ 
tional  flexibility  to  the  system  designer  and  avoiding  fine  tuned  systems  by 
augmenting  the  capability  of  the  1553  bus. 

The  recommended  development  consists  of  adding  an  augmenting  bus  to  the 
MIL-STD-1553  configuration.  The  augmenting  bus  would  have  no  protocol,  no  bus 
controller,  and  no  control  capability.  The  use  of  the  augmenting  bus  would  be 
entirely  under  the  control  of  the  serial  data  bus  controller.  The  augmenting 
bus  would  allow  high  data  rate  transfers  of  Block  and  String  information  be¬ 
tween  any  elements  of  the  system  without  restricting  the  use  of  the  serial 
bus.  The  processing  of  requests  for  augmenting  bus  utilization  and  the  as¬ 
signment  of  the  transmitting  element  and  the  receiving  elements  for  the  aug¬ 
menting  bus  would  be  through  and  by  the  standard  1553  serial  bus. 

The  implementation  details  require  study  beyond  the  scope  of  this  effort, 
however,  to  illustrate  the  concept  the  following  details  are  given  as  a  possi¬ 
ble  means  of  implementation.  A  representative  configuration  is  shown  in  Fig¬ 
ure  7.  An  eight  bit  plus  parity  parallel  bus  augmenting  configuration  is  de¬ 
fined.  Data  format  would  be  NRZ  (nonreturn  to  zero)  at  a  500  KHz  rate.  Each 
bit  and  the  parity  bit  would  be  transmitted  via  a  balanced  voltage  interface 
circuit  which  would  be  interfaced  as  a  tri-state  buffer  (recommended  in 
6.2. 1.2.2).  This  interface  would  limit  the  number  of  units  connected  to  the 
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bus  to  approximately  10,  however,  the  use  of  bus  biasing  provisions  In  only 
one  unit  to  allow  a  greater  number  of  units  should  be  investigated.  If  the 
number  of  units  connected  to  a  single  electrical  augmented  bus  cannot  be 
increased  beyond  10,  bidirectional  buffers,  with  a  one  bit  time  delay  to 
extend  the  bus,  would  be  feasible  and  could  be  incorporated  in  the  Mission 
Computer(s) ;  however,  this  approach  is  not  recommended  since  it  restricts  the 
flexability  in  bus  implementation. 

Using  the  configuration  of  Figure  7  and  the  same  conditions  discussed  in 
5. 3. 1.2  (for  the  standard  1553  remote  terminal  to  remote  terminal  asynchron¬ 
ous  data  transfer)  yields  the  following  capabilities.  Using  160,  80,  40,  and 
20  msec  bus  controller  cycle  times  and  capability  for  30  terminals  results  in 
5333,  2666,  1333,  or  666  usee  of  bus  utilization  time  to  service  each  remote 
terminal.  In  order  to  set  up  a  remote  terminal  to  remote  terminal  transfer, 
approximately  six  Command  Words,  five  Status  Words,  and  four  Data  Words  over 
the  serial  bus  are  required.  After  the  transfer  over  the  parallel  bus  is  com¬ 
plete,  two  Command  Words  and  two  Status  Words  are  required  on  the  serial  bus 
to  check  the  transfer  and  terminate  the  transaction.  The  utilization  time  of 
these  transfers  on  Che  serial  bus  is  between  408  and  520  usees.  For  the  as¬ 
sumed  cycle  times,  the  size  of  the  Block  or  String  transfers  of  16  bit  words 
In  binary  word  group  sizes  that  could  be  transmitted  over  the  500  KHz  parallel 
bus  in  the  remaining  time  is  (note  figures  in  [  J  represent  1553  serial  only 
values  from  5. 3. 1.2):  one  32  word  transaction  [0  @  32  words]  at  the  50  Hz 
(666  usec/terrainal)  sampling  rate;  one  128  word  transaction  [1  @  32  words]  at 
the  25  Hz  (1333  y sec/terminal)  sampling  rate;  one  512  word  transaction  [2  @  32 
words]  at  the  12-1/2  Hz  (2666  ( usec/terminal)  sampling  rate;  one  1024  word 
transaction  [4  @  32  words]  at  the  6-1/2  Hz  (5333  usec/terrainal)  sampling  rate. 
This  results  In  a  3200  word/sec  rate  for  transfer  between  remote  terminals 
when  operating  with  the  50  or  25  Hz  cycle  and  a  6400  word/sec  rate  for  trans¬ 
fer  between  terminals  when  operating  with  the  12-1/2  or  6-1/4  Hz  cycle  as  com¬ 
pared  to  800  words/sec  for  three  of  the  four  cycles  with  the  standard  1553 
serial  remote  terminal  to  remote  terminal  asynchronous  transfer. 
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Despite  the  increased  transfer  capability,  there  are  several  other  factors 
to  consider  regarding  the  advantages  of  an  augmenting  bus.  The  data  rate  on 
the  parallel  bus  assumed  in  the  above  examples  was  500  KHz  (chosen  to  simplify 
processing  of  the  data  and  synchronization);  however,  the  electrical  inter¬ 
faces  would  be  capable  of  up  to  approxiatemly  10  MHz  rates.  The  actual  imple¬ 
mentation  of  a  parallel  augmentation  bus  should  consider  selectable  transfer 
rates  so  that  an  individual  transfer  can  be  optimized  for  the  participants 
(example,  slower  rates  for  a  load  from  tape  and  higher  rates  for  a  memory  to 
memory  transfer).  The  above  example  assumed  that  the  parallel  bus  transfer 
must  be  completed  within  the  serial  bus  polling  cycle  time  allocated  to  one  of 
30  elements,  however,  if  no  other  parallel  bus  transfers  were  allowed  until 
the  next  complete  cycle  of  the  bus  controller,  the  entire  bus  controller  cycle 
time  could  be  used  for  a  parallel  bus  transfer  (increase  in  transfer  rate  by  a 
factor  of  30)  without  affecting  the  operation  of  the  serial  bus.  Additionally 
augmented  bus  transfers  could  be  broadcast  to  several  users  without  inhibiting 
the  serial  bus  operation  of  the  same  users.  Although  not  recommended,  because 
of  the  inflexibility  of  the  control  requirements,  the  augmented  bus  could  also 
be  shared  between  elements  on  different  serial  busses. 

The  serial  bus  transfer  from  remote  terminal  to  remote  terminal  operating 
at  6-1/4  Hz  sampling  rate  would  require  1.125  seconds  to  transfer  a  single 
1024  word  block  (7  cycles  at  128  words  per  cycle  plus  actual  transfer  time  of 
last  128  words)  whereas  using  the  parallel  augmentation  bus  operating  at  500 
KHz,  the  transfer  would  require  less  than  5  msec.  Thus,  the  receiving 
processor  could  utilize  Block  or  String  type  information  of  this  size  with  or¬ 
ders  of  magnitude  less  delay  for  the  parallel  augmentation  bus  configuration. 

Although  illustrated  with  an  electrical  parallel  bus,  the  augmenting  bus 
approach  is  entirely  compatible  with  emerging  technology  in  optical  buses 
where,  because  of  data  rate  capability,  a  parallel  configuration  is  not  re¬ 
quired.  If  the  number  of  elements  attached  to  the  augmenting  bus  cannot  be 
increased  beyond  10  using  the  line  drivers  recommended  in  6. 2. 1.2. 2,  an  opti¬ 
cal  fiber  implementation  is  the  recommended  approach. 
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The  parallel  interface  processing  would  be  a  moderately  good  candidate 
for  VHSIC  technology  where  parity  checking  and  word  formatting  could  be  per¬ 
formed  in  the  interface  chip  or  chips. 

6.4. 1.2  Bidirectional  Frequency  Multiplex  Bus 

For  general  distribution  of  interface  signals  in  a  manner  compatible  with 
the  optimum  utilization  of  common  avionics  equipment,  the  development  of  a  bi¬ 
directional  frequency  multiplex  bus  is  recommended.  The  recommended  bus  dis¬ 
cussed  in  5. 3. 2. 2  would  provide: 

a.  7  channels  of  34  MHz  bandwidth  (17  MHz  information) 

b.  7  channels  of  10  MHz  bandwidth  (5  MHz  information) 

c.  7  channels  of  1  MHz  bandwidth  (500  KHz  information) 

with  the  different  bandwidth  channels  intermixed  over  an  approximate  operating 
frequency  range  of  500  MHz  to  1.0  GHz. 

The  development  would  be  for  a  bus  configuration  as  illustrated  in  Figure 
5  and  would  include:  bus  frequency  conversion  modules,  bus  couplers  (trans¬ 
mit,  receive,  and  transmit/receive),  and  in-line  amplifier  and  filter  assem¬ 
blies. 

The  bus  should  be  compatible  with  up  to  300  feet  of  cable  and  30  couplers 
by  the  use  of  the  in-line  amplifiers.  The  frequency  converters  should,  as  a 
minimum,  be  compatible  with: 

a.  Baseband  conversion  for  the  video  interface  signals  of  6. 2. 1.4  (17 
MHz  information  channels  only). 

b.  70  MHz  IF  conversion  compatible  with  the  interface  of  6. 2. 1.5  (all 
three  bandwidth  channels). 
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c.  Baseband  conversion  for  the  amplitude  analog  interface  of  6. 2. 1.3.1 
(500  KHz  information  channels  only). 

However,  the  module  for  conversion  from  the  bus  frequency  to  the  desired  in¬ 
terface  need  only  incorporate  one  interface  output.  The  up  converter  for  on 
bus  coupling  should  be  compatible  with  all  interfaces  applicable  to  the  chan¬ 
nel  capability  (i.e. ,  convertors  with  17  MHz  bandwidth  channel  assignments 
should  be  compatible  with  accepting  either  video  or  IF  input  signals). 


6.4.2  Hardware  Developments 


6.4.2. 1  Avionics  Interface  Unit  (AIU)  < 

The  proposed  architecture  (see  Figures  1  to  3)  is  based  on  the  utiliza¬ 
tion  of  standardized  AIU's.  These  units  will  perform  functions  similar  to 
those  performed  by  the  Computer  Signal  Data  Converter  (CSDC)  in  the  F-14A  and  ‘ 

the  Comnuni cat ions  Systems  Control  (CSC)  in  the  F/A-18.  However,  the  proposed 
architecture  differs  from  that  of  the  F-14A  or  F/A-18  in  several  ways. 


6.4.2. 1.1  Concept 


In  the  proposed  architecture,  a  minimum  of  two  AIU's  are  utilized  in  or¬ 
der  to  alio?  redundant  or  back-up  capabilities  in  case  of  an  inoperative  AIU 
due  to  failure  or  damage.  By  functional  partitioning  between  AIU's,  back-up 
capability  is  maintained,  e.g.,  TACAN  and  ADF  separated,  ACLS  and  DDL  sepa¬ 
rated.  Utilizing  redundant  assets  via  separate  AIU's  removes  a  central  point 
system  failure,  e.g.,  two  UHF  radio  coranunications  systems  have  totally  sepa¬ 
rate  redundant  paths.  Redundant  audio  and  tone  generators  as  well  as  partial¬ 
ly  redundant  display  and  control  interfaces  could  allow  system  operation  with 
partial  failures  in  both  AIU's.  Subsystems  that  do  not  require  redundancy  in¬ 
terface  with  only  one  AIU, 

The  reasons  for  using  a  multiple  AIU  approach  are  several: 


92 


Report  No.  NADC  81235-20 


a.  Provide  modularized  I/O  to  accommodate  existing  systems  as  well  as 
future  technology. 

b.  Reduce  interconnect  wiring  to  reduce  weight  and  failures  by  incor¬ 
porating  interconnects  within  the  AIU. 

c.  Allow  redundancy  where  it  is  required  and  utilize  nonredundant  sub¬ 
system  functions  within  the  same  architecture. 

d.  Allow  control  of  subsystems  within  the  architecture  to  minimize  in¬ 
terconnects  and  accommodate  human  factors  considerations. 

e.  Allow  for  growth  without  drastic  changes  In  the  architecture  while 
maintaining  maximum  practical  commonality. 

f.  Eliminate  the  need  to  simultaneously  provide  for  multiple  platform 
interface  requirements  within  the  individual  subsystems. 

g.  Separate  signal  conditioning  from  signal  processing  to  allow  for  ex¬ 
pansion  of  processing  capabilities. 

h.  Allow  for  aircraft  peculiar  requirements  in  order  to  effectively  im¬ 
plement  achievable  commonality. 

1.  Allow  for  upgrading  subsystems  by  minimizing  the  impact  of  changes 
due  to  the  utilization  of  Individual  subsystem  interface  modules. 

j.  Provide  a  mechanism  whereby  subsystem  developers  can  supply  parts  of 
the  aircraft  interface  and  can  be  held  responsible  for  performance 
while  allowing  for  Navy  commonality. 

6. A. 2. 1.2  Requirements 

The  general  functions  to  be  perforrod  by  the  AICJ’s  are  as  follows: 
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Adapt  subsystem  (either  existing  or  future)  interface  requirements 
to  the  avionics  architecture. 

Provide  interconnect  wiring  between  subsystems. 

Replace  aircraft  blanking  functions. 

Perform  fail  safe  switchover  of  redundant  assets. 

Provide  single  point  fail  safe  biasing  for  line  receivers  interfaced 
to  the  AIU. 

Provide  unique  display  and  control  command/output  functions  for  all 
subsystems  including  warning  lights. 

Provide  redundant  (between  AIU’s)  antenna  control  for  flight  safety 
subsystems. 

Provide  distribution  bus  adaptor  ports  (example,  MIL-STD-1553/A/B 
long  stub  transformers). 

Provide  distribution  bus  terminations  where  applicable. 

Provide  device  code  reassignment  to  accommodate  nultiplatfonn  sub¬ 
systems. 

Provide  buffer  and  distribution  of  master  clock  signals. 

Provide  low  frequency  sync  signal  to  advisory  and  warning  displays. 
Provide  audio  volume  compensation  and  generate  all  warning  tones. 
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n.  Provide  broadcast  of  flight  dynamics  to  all  subsystems  (velocity, 

altitude,  drift  angle,  pitch  angle,  roll  angle,  roll  rate,  and  head¬ 
ing  rate) . 

6. 4. 2. 1.3  Configuration 

A  configuration  for  the  AIU  which  will  allow  maximization  of  compliance 
with  the  avionics  architecture  requirements  has  been  generated.  The  configu¬ 
ration,  conceptualized  in  Figure  8,  consists  of: 

a.  Government  Furnished  Equipment: 

o  AIU  case  and  power  distribution  backplane  wiring 
o  Input  power  filtering  and  DC  power  supply  module 
o  General  purpose  microprocessor  with  random  access  memory 
o  Audio  output  and  tone  generator 
o  Blank  modules  for  unused  capacity. 

b.  Platform  Contractor  Furnished  Equipment  (PCFE): 

o  Mission  computer  interface  module 
o  Display  and  control  interface  module 

o  Signal  distribution  backplane  wiring 

o  Extender  module  to  allow  piggyback,  if  required. 

c.  Subsystem  interface  modules  produced  by  the  subsystem  manufacturers 
for  each  platform  if  required.  Control  of  the  AIU  interface  would 
be  via  interface  control  agreements  between  the  platform  and  subsys¬ 
tem  contractors.  A  two  card  module  is  envisioned  where  the  design 
of  the  AIU  interface  card  is  controlled  by  the  platform  contractor 
and  built  by  the  subsystem  contractor  with  the  other  card  (subsystem 
interface  card)  designed  and  built  by  the  subsystem  contractor. 
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6. 4. 2. 2  Antenna  Selection  Unit 

In  order  to  minimize  the  Impact  of  aircraft  "antenna  farms, “  particularly 
on  tactical  aircraft,  the  airframe  manufacturer  typically  designs,  builds,  and 
tests  an  antenna  selection  unit  to  allow  subsystems  to  share  limited  antenna 
“real  estate."  The  efforts  of  the  individual  contractors  should  be  consoli¬ 
dated  to  provide  a  GFE  unit. 

6. 4. 2. 2.1  Concept 

The  antenna  selection  unit  should  be  controlled  via  the  AIU's  as  shewn  In 
Figures  1-3  in  order  to  serve  the  requirements  of  the  Individual  subsystems. 
Fail  safe  interconnects  of  the  AIU's  will  be  required  for  redundancy  and  back¬ 
up  subsystems  to  preclude  the  possibility  of  an  AIU  failure  disabling  the  sub¬ 
system. 

6. 4. 2. 2. 2  Requirements 

A  low  loss  30  MHz  to  2.0  GHz  band  antenna  sharing/switching  unit  is  re¬ 
quired  to  provide  VHF/UHF  comnunicatlons  ,  UHF  DDL,  TACAN,  and  IFF  upper  and 
lewer  hemisphere  coverage  and  provide  switching  for  the  lewer  hemisphere  UHF 
ADF .  Configurations  will  require  fail  safe  operation  for:  lower  hemisphere 
VHF/UHF  Communications,  TACAN  operation  in  the  presence  of  a  UHF  ADF  failure, 
UHF  ADF  operation  in  the  presence  of  a  TACAN  failure,  and  upper  hemisphere  IFF 
operation.  The  configuration  mast  allow  for  four  VHF/UHF  radio  receivers  and 
three  VHF/UHF  radio  transmitters  with  fail  safe  operation  for  either  of  two 
R/T  units.  Additionally,  manual  or  automatic  upper  lewer  hemisphere  antenna 
selection  (UHF,  or  TACAN/IFF)  must  be  provided.  Simultaneous  operation  of  one 
UHF  R/T,  UHF  ADF,  and  either  TACAN  or  IFF  is  required. 
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6. 4. 2. 2. 3  Configuration 

The  recommended  configuration  for  the  Antenna  Selection  Unit  is  two  iden¬ 
tical  fail  safe  RF  switching  units  controlled  by  redundant  AIU  interface  ele¬ 
ments  as  configured  in  Figures  1-3.  Antenna  switching  logic  should  be  con¬ 
trolled  by  the  CFE  display  and  control  module  to  allow  for  different  aircraft 
conf igurutions.  The  upper  lower  antenna  selection  circuitry  should  be  part  of 
the  GFE  audio  and  tones  interface  module. 

6. 4. 2. 3  Load  and  Memory  Device 

The  architecture  of  Figures  1-3  assumes  that  a  preflight  Load  and  Memory 
Device  will  provide  initial  avionics  control  settings,  a  failure  recording 
mechanism,  backup  storage  of  current  configuration  for  both  core  and  mission 
avionics,  and  a  priori  data  input.  The  development  of  this  device  should  be 
persued  in  a  manner  consistant  with  providing  a  GFE  unit. 

6. 4. 2. 3.1  Concept 

The  Load  and  Memory  Device  would  be  controlled  entirely  by  the  Mission 
Computer( s) .  Information  storage  and  retrieval  would  be  via  remote  terminal 
to  remote  terminal  block  transfers  over  the  augmented  MIL-STD-1553  bus.  The 
main  purpose  of  this  device  would  be  to  configure  variable  memory  prior  to 
flight  and  not  to  provide  mass  storage  for  individual  subsystem  memories. 

6. 4. 2. 3. 2  Requirements 

The  actual  requirements  for  the  intended  use  could  most  probably  be  sa¬ 
tisfied  by  an  electronically  alterable,  500  kilobit  memory  with  a  10  kilo  bit/ 
second  access  time.  Technology  in  bubble  memories  that  exists  today  will 
allow  a  2  megabit  memory  (125,000  16  bit  words)  with  a  100  kilobit/second 
(6,250  16  bit  words/sec)  memory  to  memory  transfer  rate.  Since  the  technology 
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exists  to  provide  for  excess  above  the  actual  requirements  in  a  small  volume 
package  the  pursuit  of  this  technology  to  satisfy  the  requirement  is  recom¬ 
mended. 


6. A. 2. 3. 3  Configuration 

The  configuration  envisioned  is  for  a  cockpit/station  mounted  unit  with  a 
portable  plug-in  module  (cassette)  containing  the  memory  device.  The  proposed 
use  would  require  classified  (confidential)  cassettes,  however,  it  may  allcw 
declassification  of  units  that  currently  contain  classified  permanent  memory 
(e.g.,  threat  tables  in  EW  equipment). 

6. A. 2. 4  Clock 


The  architures  of  Figures  1-3  assume  an  independent  clock  signal  will  be 
provided  to  elements  with  time  multiplex  digital  interfaces.  The  clock  signal 
would  be  utilized  to  provide  simplified  synchronization  of  the  parallel  por¬ 
tion  of  the  augmented  MIL~STI>-1 553  bus.  Additionally,  the  clock  would  provide 
digital  output  for  cockpit/station  time  of  day  display. 

6.A.2.A.1  Concept 

The  clock  element  is  assumed  to  be  part  of  the  Display  and  Control  Sub¬ 
system  with  time  of  day  setting  via  the  Mission  Computer(s)  using  either  an 
external  input  (broadcast  time  reference  or  deck  edge/microwave  deck  link  used 
for  inertial  allignment)  or  manual  input  through  a  control  keyboard. 

6. A. 2. A. 2  Requirements 

The  recommended  augmented  data  bus  transmission  rate  is  500  KHz,  hence,  a 
square  wave  clock  rate  of  250  KHz  would  allow  synchronization  (500  kilobaud). 
The  clock  should  operate  with  a  10  MHz  reference  to  allow  high  speed  data  syn¬ 
chronization.  The  clock  should  provide  at  least  five  external  sync  outputs 
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via  the  line  driver  recommended  in  6. 2. 1. 2.1  in  order  to  insure  comparability 
with  driving  a  minimum  of  30  units  without  additional  buffering.  The  clock 
should  also  be  capable  of  synchronizing  to  one  external  input.  This  input 
could  be  utilized  for  synchronizing  clocks  between  aircraft  (via  JTIDS  for 
example)  in  order  to  accommodate  cooperative  tactics  (cooperative  jamming  for 
example) . 

Redundant  clock  interconnections  are  not  recommended.  In  the  event  of 
clock  failure  a  backup  synchronization  mechanism  exists  via  the  MIL-STD-1553 
serial  bus  Synchronize  mode  commands  and  use  of  the  internal  clock  in  each 
equipment  interfaced  to  the  augmented  bus. 

6. 4. 2. 4. 3  Configuration 

The  clock  unit  is  assumed  to  be  an  integral  part  of  the  Display  and  Con¬ 
trol  Subsystem  with  time  of  day  display  provided  by  that  subsystem.  The  clock 
element  could  be  part  of  the  Display  and  Control  Processor,  with  only  one 
processor  actually  utilized  to  derive  external  sync  outputs. 

6.4.3  Technology  Development 
6.4.3. 1  IF  Multiplex  Switch 

As  discussed  in  4.3.4  and  5.2  the  development  of  a  70  MHz  IF  multiplex 
switch  is  recommended.  The  recommended  configuration  is  a  four  by  four  matrix 
to  provide  unidirectional  signal  distribution.  It  is  recommended  that  this  be 
a  self  contained  unit  with  fail  safe  input  to  output  connections  and  digital 
control  via  the  digital  interface  recommended  in  6. 2. 1.2. 
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Subsystem  Architecture,  Unit  Configuration  and  the  Reliability  Impact 


Introduction 


The  purpose  of  this  analysis  is  to  determine  the  effect  on 
reliability  of  adding  series  elements  to  a  subsystem  architecture. 

The  intent  is  to  generate  a  means  of  assessing  the  reliability  impact 
of  adding  additional  units  to  the  subsystem  configuration,  particularly 
for  flight  safety  critical  subsystems  where  parallel  redundancy  is 
incorporated.  The  configurations  considered  are  shown  in  figure  1. 

The  series  configuration  will  be  considered  only  as  a  reference  point 
from  which  to  evaluate  series  parallel  flight  safety  critical  subsystems. 
In  this  analysis  all  elements  of  the  architecture  will  be  considered 
active  (i.e.  operating,  even  though  some  or  all  outputs  are  not  utilized) 
over  the  entire  operating  time  of  the  subsystem  and  element  interconnects 
will  be  considered  failure  free.  Additionally,  for  simplicity  and  in 
order  to  allow  generalized  conclusions  all  elements  are  assumed  to  have 
identical  failure  (hazard)  rates,  and  an  exponential  density  function 


i.e. : 


p(t)  =  e~Xt 


(1) 


where  p(t)  is  the  probability  of  success  as  a  function  of  time  and  X 
is  the  constant  failure  rate  (failures  per  unit  time)  which  is  equal  to 
1/9e  'where  9e  is  the  Mean  Life  of  the  element. 


Care  should  be  taken  in  interpreting  the  data  that  follows  in  that 
no  attempt  is  made  to  account  for  the  fact  that  after  a  repair  a  sub¬ 
system  is  assumed  to  be  in  the  same  status  as  a  new  system  (i.e.  no  time 
deterioration) .  This  assumption  is  consistant  with  the  exponential  den¬ 
sity  function  in  that  all  failures  are  chance  failures  and  have  a  con¬ 
stant  hazard  rate  ( instantaneous  failure  rate)  over  all  time.  This 
assumption  is  not  true  for  general  avionics  equipment  (e.g.  cooling  fans 
wear  out).  The  implied  equivalence  between  MT3F  (Mean  Life  Between  Failures) 
of  actual  equipment  and  the  calculated  Mean  Life  in  what  follows  is  not 
accurate  since  wear  out  is  not  accounted  for. 
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Series  Configuration 

The  Reliability  Function  for  a  subsystem  with  a  series  configuration 

of  identical  failure  rate  elements  is: 

Rc(t)  =  p(t)n  =  e-nAt  .  [?) 

The  Mean  Life  is  defined  as: 

00  00 

0c  s  /  Rc(t)dt  =  ;  e_nAt  dt  =  1  (3) 

0  0 

The  effect  on  the  Mean  Life  of  a  cascaded  element  subsystem  due  to 
the  addition  of  one  additional  element  may  be  expressed  as: 

0c (n+1)  nX  n 

Qctnl  =  (n+1 )X  =  n+1  .  (4) 

Series  Parallel  Configuration 

From  table  8.2  item  4.c  of  the  referenced  literature  a  subsystem 
with  a  series  parallel  configuration  of  two  identical  parallel  active 
elements  with  an  exponential  failure  density  has  a  Reliability  Function 
given  by: 

Rs(t)  =  (p(t)z  -  2p { t } ) n  .  (5) 

The  Mean  Life  is: 

9s  =  7  R_(t)dt 

Substituting  ( 1 )  in 
yields:  Q 


(5)  and  (5)  in  (6)  and  performing  the  integration 


1  “  i 


(2)n'J  n! 


J=0Tn+j)  j!  (n-j)! 


(T) 


i 

i 

i 

) 

» 

s 

t 

1 
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The  values  of  1©  for  both  the  series  and  series  parallel  config¬ 
urations  equations  of  figure  1 (equations  (3)  and  (7))  are  plotted  as 
continuous  functions  of  n  for  illistrative  purposes  in  figure  2.  It 
should  be  noted  that  n  may  have  integer  values  only  and  these  functions 
are  not  continuous.  Figure  2  illustrates  the  improvement  in  Mean  Life 
of  the  series  parallel  configuration  relative  to  the  series  configuration 
and  the  reduction  in  Mean  Life  due  to  the  addition  of  elements  to  a  sub¬ 
system  configuration.  In  interpreting  figure  2  as  well  as  equations  (5) 
and  (7)  it  should  be  noted  that  Mean  Life  is  defined  in  relation  to  a 
subsystem  failure.  For  the  series  configuration  a  subsystem  failure 
is  synonymous  with  an  element  failure,  however,  for  the  series  parallel 
configuration  equations  (5)  and  (7)  and  hence  figure  2  assume  no  repair 
is  made  until  a  sufficient  number  of  elements  fail  to  cause  a  subsystem 
failure . 

Series  Parallel  Configuration  With  Post  Flight  Maintenance 


In  section  8.6  of  the  referenced  literature  for  an  active  series 
parallel  subsystem  for  which  maintenance  is  performed  at  intervals  of 
time  T  the  Reliability  Function  is  given  as: 

Rm(t)  =  |rs(T)]  ^  (Rs(t)),  where  (< 

t=jT+x 

j=Q ,1,2,.... 

0<t<T 

and  Rs(y)  is  the  Reliability  Function  of  the  subsystem  without  maintenance 
(see  equation  5).  The  Mean  Life  of  the  subsystem  is  given  by: 

00  pOO 

0m  s  /  Rm(t)dt  =2 
o  |J=‘ 


Rs(T 


- 


Rs ( x ) dr 


(SJ 


and  by  using  the  identity 


as: 


00 

L 

j=o 


T 

9m  =  /  Rs  (x)dx 
o 


2 

1— X 


1-Rs  (T) 


the  Mean  Life  is  restated 


(10) 
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Substituting  (1)  in  (5)  and  (5)  in  (10)  yields: 


Equation  (11)  has  been  evaluated  as : 


9m  =  -r  4=2- 


(-1)J  (2)n~J  n! 
(n+j)  i !  ( n- i T ! 


1_e-(n+j)AT) 


1-e~n^T  (2-e_XT)n 


(11) 


(12) 


By  inspection,  as  T  approaches  ®(i.e.  no  maintenance  before  a  subsystem 
failure)  equation  (12)  becomes  identical  to  (7): 

Figure  3  is  a  plot  of  the  ratio: 

AOm(n)  _  Qm(n) 

AGm(n=1)  0m(n=1) 

as  a  function  of  n  for  three  values  of  AT. 

Again,  for  illustrative  purposes  figure  3  is  plotted  as  a  continuous 
function  despite  the  fact  that  n  is  restricted  to  integer  values.  As 
noted  above  as  T  approaches  ®  (equivalent  to  AT»1)  Gm  is  equivalent' to 
0s  for  a  two  element  series  parallel  configuration  of  elements,  hence 
the  trace  in  figure  3  is  equivalent  to  the  two  element  series  parallel 
trace  of  figure  2  with  the  maximum  value  normalized  to  1 .  It  is 
interesting  to  note  that  for  AT«1  (i.e.  maintenance  in  intervals  much 
less  than  the  M73F  of  the  subsystem  elements)  the  sensitivity  of  the 
series  parallel  configuration  to  the  number  of  elements  (lower  trace 
of  figure  3)  is  identical  to  that  of  the  nor.-redundant  series  config¬ 
uration  (lower  trace  of  figure  2).  It  should  be  noted  however  that 
only  the  sensitivity  ratios  are  identical,  the  absolute  values  vary 
drastically. 
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(For  example,  a  single  element  subsystem  (series)  with  an  element 
Mean  Life  of  100  hours  has  a  subsystem  Mean  Life  of  100  hours;  a 
two  element  parallel  subsystem  with  an  element  Mean  Life  of  100  hours 
has  a  subsystem  Mean  Life  of  150  hours  if  no  maintenance  is  performed 
until  a  subsystem  failure  occurs  and  a  Mean  Life  of  5100  hours  if  after 
each  2  hour  flight  a  redundant  element  failure  is  corrected.) 

Discussion 

Examination  of  figure  3  illustrates  that  when  maintenance  is  con¬ 
sidered  the  proportional  effect  on  subsystem  reliability  is  considerably 
greater  than  would  be  predicted  by  typical  redundant  system  calculations. 
Figure  4  is  a  plot  of  the  ratio  ''  using  equation  (12)  to  generate  the 

values  of  0m(n)  and  Qra(n+1 ) .  The  figure  shows  the  incremental  effect  of 
adding  one  more  element  to  a  subsystem  of  n  elements.  The  lower  trace 
(XT«1)  is  characteristic  of  a  real  world  avionics  system  where  the  MTBF 
is  significantly  greater  than  a  typical  flight  duration  (i.e.  maintenance 
period)  and  again  interestingly  is  identical  to  a  plot  for  the  series  con¬ 
figuration  (equation  (4)).  Prior  to  attempting  this  analysis  an  arbitrary 
criteria  that  not  more  than  a  ten  percent  reduction  in  the  MTBF  of  a  Sub¬ 
system  should  be  tolerated  to  accommode  the  addition  of  a  single  series 
element  (with  parallel  redundancy)  was  established.  This  criteria  can  be 
met  only  for  a  series  parallel  subsystem  configuration  that  consists  of 
9  or  more  element  pairs  when  the  effects  of  maintenance  are  considered. 
Since  the  sensitivity  to  adding  one  series  element  with  parallel  redundance 
asymptotically  approaches  1  any  criteria  more  stringent  than  10%  would  not 
allow  the  addition  of  a  single  element  pair  unless  the  subsystem  was  com¬ 
prised  of  a  large  number  of  element  pairs. 

Conclusion 

The  addition  of  elements  to  a  series  parallel  redundant  subsystem 
architecture  should  be  considered  as  if  there  was  no  redundancy.  Although 
the  reliability  achieved  by  the  series  parallel  redundant  configuration 
is  significantly  greater  than  the  series  configuration  the  sensitivity 
to  the  number  of  elements  is  the  same  when  real  world  maintenance 


A-9 


9n(n*1 ) 


Report  No.  NADC  81235-20 


practices  for  avionics  system  are  considered. 

Figure  5  shows  the  ratio  of,  Mean  Life  for  a  series  parallel  sub¬ 
system  with  repair  at  intervals  significantly  less  than  the  element 
Mean  Lif$  to  the  Mean  Life  of  the  same  subsystem  with  no  repair  until 
subsystem  failure.  The  reliability  increase  achieved  by  repair  of 
failed  elements  after  each  flight  can  only  be  realized  if  fault  de¬ 
tection  to  indicate  element  failure  is  incorporated.  Figure  5  emphasises 
that  reliable  fault  detection  and  reporting  should  be  given  special 
attention  in  any  architectural  design. 
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Figure  5.  Improvement  in  Mean  Life  achieved  by  post 
flight  maintenance  of  a  series  parallel 
configuration  versus  number  of  series  elements. 
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DEFINITION  OF  TERMS 


A  number  of  terms  utilized  in  this  report  have  become  diluted  by  applica¬ 
tion  of  more  than  one  meaning.  The  definition  of  these  terms  as  they  are  uti¬ 
lized  in  this  report  are  as  follows: 

Weapons  System.  An  entire  military  platform  consisting  of  the  ve¬ 
hicle,  the  crew,  consumables,  systems  and  subsystems  required  to  perform 
one  or  more  military  missions. 

System.  That  portion  of  the  weapons  system  required  to  perform  a 
specific  task.  Example:  bombing  system  includes  navigation,  targeting, 
and  weapons  release/ guidance. 

System  Avionics.  That  portion  of  a  system  primarily  associated  with 
collecting  and  processing  information  in  electronic  formats.  Example: 
navigation  processing  and  target  tracking. 

Weapons  System  Avionics.  All  the  components  of  each  of  the  Avionics 
Systems  incorporated  in  a  weapons  system.  The  Weapons  System  Avionics 
must  be  considered  as  an  entity  in  order  to  account  for  the  requirements 
of  shared  equipment.  Example,  the  Heads  Up  Display  is  part  of  the  Bomb¬ 
ing  System  as  well  as  the  Flight  Control  System. 

Subsystem.  A  stand-alone  entity  that  performs  a  specific  function 
in  support  of  one  or  more  systems  or  avionics  systems.  Example:  iner¬ 
tial  navigation  or  radar. 
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DEFINITION  OF  TERMS  (continued) 


Specialized  Subsystem.  A  subsystem  that  has  peculiar  requirements 
that  do  not  allow  complete  integration  into  an  avionics  system.  Example: 
manually  updated  doppler  navigation  or  manually  operated  radar  target 
tracking. 

Avionics  Architecture.  The  definition  of  the  requirements  necessary 
to  perform  all  electronic  information  processing  tasks  in  terms  of  equip¬ 
ment  required,  functional  allocations  for  equipment,  and  how  the  equip¬ 
ment  interface  with  each  other  and  the  operator.  This  definition  may 
apply  to  weapons  system  avionics,  system  avionics,  or  an  individual  sub¬ 
system. 

Multiplatform  Avionics  Architecture.  That  portion  of  the  Weapons 
System  Avionics  Architecture  designated  to  be  common  among  platforms.  It 
includes  all  elements  of  the  Weapons  System  Avionics  Architecture  except 
the  specific  equipment  (subsystems)  to  be  utilized,  functional  alloca¬ 
tions  for  individual  elements  of  a  subsystem,  interfaces  between  elements 
of  a  specialized  subsystem.  Functional  allocations  for  equipment  (sub¬ 
systems)  are  included  only  to  the  extent  of  defining  what  will  not  be 
performed  by  the  subsystems. 

Core  Avionics.  The  avionics  systems  whose  functions  are  universally 
applicable  among  most  aircraft  types.  These  systems  include  voice  com¬ 
munications,  data  communications,  navigation  systems  and  aids,  portions 
of  the  flight  control  system  and  avionics  controls  and  displays. 
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DEFINITION  OF  TERMS  (continued) 


System  Engineering.  The  design  of  a  complex  interrelation  of  many 
elements  (a  system  or  subsystem)  to  achieve  a  performance  requirement, 
taking  into  consideration  all  the  elements  (including  the  operator/user) 
related  in  any  way  to  the  system  or  subsystem.  The  result  of  the  design 
effort  is  a  system  or  subsystem  configuration  and  a  functional  allocation 
for  each  element  of  the  system  or  subsystem. 

Systems  Integration.  The  process  of  interconnecting  a  subsystem  to 
a  weapons  system  in  such  a  manner  as  to  achieve  greater  capability  than 
is  inherent  in  either  the  original  system  or  any  of  the  interconnected 
subsystems. 
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AAES 

ABC 

ac 

ACLS 

ADF 

ADI 

AIDS 

AIU 

AM 

AOA 

ARI 

ARINC 

AVCS 

A/D 

BC 

BDHI 

BIT 

CAINS 

CFE 

COMSEC 

CPLR 

CSC 

CSDC 

CV 

CVS 

dB 

dBm 

dc 


GLOSSARY 

Advanced  Avionics  Electrical  System 
ficticious  contractor 
alternating  current 
Automatic  Carrier  Landing  System 
Automatic  Direction  Finding 
Attitude  Director  Indicator 
Advanced  Integrated  Display  System 
Avionics  Interface  Unit 
Amplitude  Modulation 
Angle  of  Attack 
Attitude  Reference  Indicator 
Aeronautical  Radio  Incorporated 
Avionics  Components  and  Subsystems 
Analog  to  Digital 

Bus  Controller 

Bearing  Distance  Heading  Indicator 
Built  in  Test 

Carrier  Aircraft  Inertial  Navigation  System 
Contractor  Furnished  Equipment 
Communications  Security 
Coupler 

Communications  System  Control 
Computer  Signal  Data  Converter 
Aircraft  Carrier 
Correlation  Velocity  Sensor 

deci  Bell 

deci  Bell  relative  to  a  milliwatt 
direct  current 
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DDL 

DECK 

DOD 

DSB 

EIA 

EMI 

ESM 

EW 

FED 

FLIR 

FM 

FSK 

GFE 

GFS 

GHz 

GPS 

GSE 

HF 

HSI 

Hz 

ICS 

IEEE 

IF 

IFF 

IFPM 

USA 


GLOSSARY  (continued) 

Digital  Data  Link 

Deceptive  Electronic  Countermeasures 
Department  of  Defence 
Double  Side  Band 

Electronic  Industries  Association 
Electromagnetic  Interference 
Electronic  Support  Measures 
Electronic  Warfare 

Federal 

Forward  Looking  Infrared  Receiver 
Frequency  Modulation 
Frequency  Shift  Keying 

Government  Furnished  Equipment 
Government  Furnished  Software 
giga  Hertz 

Global  Positioning  System 
Ground  Support  Equipment 

High  Frequency 

Horizontal  Situation  Indicator 
Hertz 

Intercommunications  System 

Institute  of  Electrical  and  Electronic  Engineers 
Intermediate  Frequency 
Identification  Friend  or  Foe 
In-flight  Performance  Monitoring 
Integrated  Inertial  Sensor  Assembly 
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GLOSSARY  (continued) 


ILS 

Instrument  Landing  System 

I/O 

Input/Output 

JTIDS 

Joint  Tactical  Information  Distrubition  System 

KHz 

kilo  Hertz 

LCC 

Life  Cycle  Cost 

LF 

Low  Frequency 

LF/ADF 

Low  Frequency/ Automatic  Direction  Finding 

LORAN 

Long  Range  Aid  to  Navigation 

Lx 

960  to  1215  MHz  band 

MESK 

Mission  Essential  Subsystem  Matricies 

MHz 

mega  Hertz 

MIL 

Military 

MLS 

Microwave  Landing  System 

MMR 

Multimode  Receiver 

msec 

millisecond 

NAC 

Naval  Avionics  Center 

NAVAIR 

Naval  Air  Systems  Command 

NAVAIRDEVCEN 

Naval  Air  Development  Center 

NRZ 

Non  Return  to  Zero 

nsec 

nanosecond 

NTDS 

Navy  Tactical  Data  System 

OMEGA 

not  an  acronym 

OPNAV 

Offices  of  the  Chief  of  Naval  Operations 

OPNAVINST 

OPNAV  Instruction 

PCFE 

PM 


Platform  Contractor  Furnished  Equipment 
Phase  Modulation 
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PROTEUS 

PRP 

QPL 

R 

RF 

RT 

R/T 

SAE 

SEMP 

STD 

T 

TACAN 

TEMPEST 

TIES 

UHF 

V 

VHF 

VHSIC 

VLF 

VOR 

VOR/LOC 

XYZ 


usee 


GLOSSARY  (continued) 

not  an  acronym 

Pulse  Repetition  Period 

Qualified  Parts  List 

Receive 

Radio  Frequency 
Remote  Terminal 
Receive/Transmi t 

Society  of  Automotive  Engineers 
Standard  Electronic  Module  Program 
Standard 

Transmit 

Tactical  Air  Navigation 
not  an  acronym 

Tactical  Information  Exchange  System 
Ultra  High  Frequency 

Volt 

Very  High  Frequency 

Very  High  Speed  Integrated  Circuits 

Very  Low  Frequency 

VHF  Omni  Range 

VOR/Localizer 

ficticious  contractor 

microsecond 
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